I'm trying to figure out how to add an extra security layer to my WebApp cURL calls going to my API Engine.

I have a WebApp that sends data to an API engine I made.

My API will have access to the filesystem and therefore has to be quite secure so that there is no way someone can execute a script on the server.

The idea I had to further secure it si to have a salt on the WebApp and the same one on the API engine, the WebApp will send the cURL with an hashed timestamp and the real timestamp, plus any other request, example:


$hash = "1h2k3jklh";
$tstamp = time();
$hashed_tmstamp = md5($tstamp . $hash);

$data_to_send = [
    'time' => $tstamp,
    'auth' => $hashed_tmstamp,
    'foo'  => "bar"

On the API side I will check if auth is equal to the sent timestamp hashed with the API hash (which is the same as the WebApp one).

This way if the auth is copied and send with a new request will always fail as timestamp updates. I made a little graphical example to better understand.

enter image description here

There is a point, if "the man in the middle" can copy the auth can also copy time and can send requests always with the same time and auth.

So I'm wondering how to solve this part as on the API side I don't have a DB to check against "already used hash".

I'm in doubt I'm probably trying to reinvent the wheel and for sure this kind of stuff has already been checked/handled.

The only point is that I do want the "standard way" but I'm trying to add extra security so that a possible hacker does not know what's on the other side.

Any advice? Also, any better idea?

  • If the client is trusted and the only worry is MitM then the entire thing is unnecessary, TLS already provides replay protection. Commented Aug 2, 2018 at 20:35
  • @AndrolGenhald ok, any extra security I can implement? You know? TLS protocols had a bug and this and that... Things change over time.
    – Mr.Web
    Commented Aug 2, 2018 at 20:40
  • 2
    You are betting on your programming skills being better than the entire community developing TLS. Trust the community. Use TLS.
    – ThoriumBR
    Commented Aug 2, 2018 at 20:54
  • Upvoted. I don't pretend to know better I just wanted an extra layer, if possible. Otherwise I'll stick with plain TLS.
    – Mr.Web
    Commented Aug 2, 2018 at 20:56
  • You can add other stuff at the application layer, it's just a pain for anyone to evaluate your scheme. Probably it will end up having some exploitable flaws and thus not give you much more than just plain old TLS, but will take time to implement (and time is money...). But the good thing is that what you do at the application layer probably won't hurt TLS. But do be sure to actually use TLS.
    – hft
    Commented Aug 2, 2018 at 21:32

1 Answer 1


I would go the exact opposite way. Put the code on github, let people fork it, send pull requests, change the code. It evolves. If you made a critical mistake, someone will notice and inform you.

And use TLS. There's a great community behind it, there are bugs, but they are so obscure most of the time that we mere mortals don't need to be worried. Misconfiguration, programming errors, logic errors and code injections are way more prevalent and exploitable than TLS bugs.

If you want to implement replay protection, use an increasing nonce. This way the server will only need to save one value - the last used nonce, and the client will have to increment it before every request. It does not need to increment by one, it can be incremented by any value. In some API's I use, the nonce is the Epoch (plus milliseconds).

Quoting Antoine de Saint Exupéry:

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

API's are meant to be simple. Don't add any mechanism if you don't need to. Adding components increases complexity, reduces performance, and it's one more thing you need to update from time to time. Keeping only essential parts reduces this burden.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .