A very good way to do this would be using a remote procedure call (RPC), probably using JSON and AJAX, or a SOAP call, using an interface (an "API") that is exposed by the web server but not published.

Require that all uses of this API must use TLS (SSL) encryption. Having done so, you can now go one step further (using Apache directives) to require that the supplicant must also possess a particular (that is to say, particularly signed) SSL certificate on their side. This will close the door to any client-side process except the ones that you expressly authorize, and it will allow you to positively identify who's calling using cryptographic means.

(In addition to good ol' Apache, also bear in mind that there are other servers out there who are specifically designed for RPC/SOAP work. You can even roll your own.)

• Important: (Open)VPN also uses TLS technology as an integral part of its operations, but you should use a completely separate(!) CA for Apache than you use with OpenVPN. You can use easyRSA in both ... separate(!) ... cases.

If the request is not authorized, do not reply at all. Leave 'em hanging. (Or, if you feel gracious, throw a faceless "404" back.)

Having thus accepted the request, of course thoroughly validate the information received, then issue database queries using SQL placeholders, not a hand-built SQL string.

So, the remote system uses these RPC-calls to obtain information securely and to post authorized updates which can be cryptographically determined to be valid and which cannot be read by anyone.

Hi Sundial,
I like you idea looks very interesting to me. I think this will be a good avenue for me to start something on API because I never worked on it before.To be frank I only know normal php which runs on apache or nginx. Now moving forward I love to implement your idea. I notice this api call are also similar to the php codes it can accept post, get etc. So how kick start on this api development do I need a separate server on this ?

Read up on things like SOAP, JSON, XML, RPC.

(Seriously ... do that.)

The actual notion is conceptually simple: you send a "packet" of information, e.g. in JSON or XML format, which specifies the name of a routine that you want to invoke on the server, and the parameters that you want to pass to it. The server returns the results, as well as an indication of whether the request succeeded or failed.

You'll also need to read up on the more-advanced mod_ssl parameters (Apache), or their nginix equivalents.

One thing that's always engaged me about this crazy business – there's always something new to learn.

Hi Sundial,
Yes I have dealt before with both JSON, SOAP, XML. The issue for example this how I have dealt before with soap.

Based on your experience which is better is it soap, json in terms of security, performance etc.Yes I agree I keep learning new stuff to improvise myself thats why I am taking this challenge to build API this time. Just need some help based on your experience too.

I have read one example is this https://www.shift8web.ca/blog/use-ph...uthentication/.

Now there are many example I am lost dont know which to pick to start and which is secured.

JSON, SOAP, etc. are, at one level, "merely transport protocols." SOAP is designed to allow clients to access unfamiliar services, and/or to insulate those clients from changes in the server and vice-versa. It really is a very big topic, and you'll need to do some on-line research to decide what's best for your use-case.

The comments that I made about using mod_ssl to secure the identity of client and(!) server is very important. But, please realize that I curried these insights from my own on-line research.

An excellent start would be to explore existing packages which are specifically designed to support secure-RPC.

If you want to go all the way to the top and start downward, look at WildFly, formerly known as JBoss®. This will give you a glimpse of what industries have done and are now doing. You will find similar application-support frameworks built on all major programming systems including PHP. It is always easier and better to look for existing work, done by qualified experts and then contributed to the community, than to start anything from ground-zero. "Best Practices™" have been widely discussed on-line, and implemented. Never start from scratch: you do not have to.

Hi Sundial.
Thank you for sharing you experiences. I appreciate it. Yes I have looked into JBoss before. Currently since I am familiar with php so I am looking into this though https://framework.zend.com/blog/2017...ap-server.html. Actually something is very confusing here is that I still dont understand what is the difference say I have a backend php code which is accepting a post submission vs this API type of implementation?

It's explained in your linked page!
If your application is private only, of course these arguments can't be taken in acount...
It's a matter of choice, if you do anything from scratch, code is tailored for your needs, but it will take some time to make tests, fix errors etc Or if you use already built framework, which can be overkill on some aspects but already tested by a number of skilled people

RPC mechanisms often use the HTTP(S) transport simply because it is widely-available. The back-end service which accepts the request and which responds to it can be written in PHP, or anything else.

You can then employ mod_ssl as previously described, in both the web-server layer and in your application code, both to secure your API and (through the use of more-advanced features) to cryptographically identify the clients who are seeking access to it.

Through the use of these features, your API can know, without a doubt, "who's making this request." The web-server can turn away unauthorized access attempts before you ever see them. You don't have to worry (as much) about "hackers" discovering and attacking you – because they can't. You can easily deploy APIs that will meet tough industry standards for information security.

In any language and environment, you can find substantial "off-the-shelf" component-ware which will do most of the heavy-lifting for you. Never "start from scratch" on this sort of thing – you simply don't have to. "It has already been done, and done very well."

Hi Keefaz,
When you say private meaning only used by our user or some limited users ? So for php do you have any suggestion to use any good framework based on your experience I know google give me a number of it like laravel etc.

Hi Sundial,
Actually currently I have fully built my application using php and mysql db. Off course most of it I did it with my own codes where I do form submission etc. So off course the form submission is a kind of back-end service which accept the request to either insert, edit or delete data.

What you mentioned here
"
Through the use of these features, your API can know, without a doubt, "who's making this request." The web-server can turn away unauthorized access attempts before you ever see them. You don't have to worry (as much) about "hackers" discovering and attacking you – because they can't. You can easily deploy APIs that will meet tough industry standards for information security.
"
Can I apply it to my current application which I have build ?

No, I don't know frameworks for your needs. I know I would start documentation search from defining communication requirements between HOST1 and HOST2.

Maybe you don't need SSL enabled for both HOST1 and HOST2 if HOST1 is the client requesting and HOST2 is the server answering

eg:

login page -> HOST1 sends login request -> HOST2 verifies
HOST2 answers login ok -> HOST1 displays it's ok

login page -> HOST1 sends login request -> HOST2 verifies
HOST2 answers login not ok -> HOST1 displays it's not ok

new account page -> HOST1 sends new account request -> HOST2 records request
HOST2 answers new account awaiting -> HOST1 displays account is awaiting confirmation

In this case only HOST2 has to have SSL enabled, HOST1 is the client

Hi Keefaz,
I found a new solution which seems to work. From HOST1 when I click say the submit button I could run an ajax script to HOST2 to do the processing work for me and reply. I dont know if this secured method ? When you say only HOST2 need to have SSL enabled meaning I need to installed and run the ssl mode on this server ?

Encrypted transport is important, especially between devices communicating via wifi network. Yes configuring SSL on HOST2 would be a big plus.
The ajax method is no more secure than a POST/GET form method.

If you want to really hide communications between HOST1 and HOST2 from the user, use server scripting and network library (curl) on HOST1, so user send informations to HOST1 which relay it to HOST2

Hi Keefaz,
Ok sure I will be adding SSL certificate on HOST2 cause its running my application there too. I dont get you when you say about the security of the ajax method? Will curl help me secure it better or can I improvise via ajax the security ?

ajax request is on client side, so any user can see HOST2 url by seeing the javascript code
curl is on server side, no way for the user to have an idea about what the server is doing with the login request