re: I have an app idea, where do I go to get it made?

quote:

---

I had very limited exposure to one API that we were using and it didn't have any limits of what someone could send in.

---

It's very rare to find an API with no limits or authentication. And untold millions of coder-hours have been spent developing methods to make sure that a request is authentic.

Generally, API requests are "signed" with a secret key which makes it basically impossible to modify the data. Even if you can read in clear text exactly the message that an app is sending, you still will not be able to change the message and pass it on to the API. The server will know that it has been modified because the signature will no longer be valid. The payload of the message is incorporated into the signature, so that a change of a single character will require a completely different signature.

And of course the secret key is generally well-protected.

In simple terms, imagine I want to send you a secret message on a piece of paper, but I have to send it with a messenger. I have a lockbox, a padlock, and a key for the padlock. You also have a padlock and a key for it. I do NOT have a key for your padlock, and you do NOT have a key for mine. How do we send secure messages to each other when a 3rd party has to carry the lockbox and we can't unlock each other's padlocks?

I put the message in the box and lock it with my padlock. The messenger carries the box to you, unable to open the box. You receive a locked box that you can't open. You put YOUR padlock on the box as well, and send it back to me via the messenger. I receive the double-locked box, and I remove my padlock. I send it back to you via the messenger. You receive the box once again, you unlock your padlock and read the message.

So that's basically how a secure connection is set up. That's how my computer or phone can send my password to a server in a way that no one can intercept it and read it. It's just that instead of a padlock, messages are encrypted. Once this is done, the server can send an authentication token for signing future messages to eliminate the extra back-and-forth, time-consuming, re-authentication process.

If you want to learn more, look up hash functions, public key encryption, https, TLS, and just follow the trail.

quote:

---

Generally, API requests are "signed" with a secret key which makes it basically impossible to modify the data. Even if you can read in clear text exactly the message that an app is sending, you still will not be able to change the message and pass it on to the API. The server will know that it has been modified because the signature will no longer be valid. The payload of the message is incorporated into the signature, so that a change of a single character will require a completely different signature.

---

For the most part, the payload of the request lives in the request body or URL and not in some hashed key, the API authorization token is found in the header. The majority of APIs are setup to where you present authorization via the request header, and if valid, it lets you through to do what you want (ie a POST request with location data in the request body) or sends the information you requested. The key has nothing to do with how the payload is sent and the contents of the request body will not alter the validity of the auth token. Sure, request over HTTPS are encrypted because it's HTTPS but that doesn't mean you can't intercept requests and change their payload via proxy, Charles and Fiddler are two programs that do this.

So, to the OP, getting the request would be the "easy" part. Figuring out an algorithm for each app to decide when to alter request and when you let them act naturally (i.e. the user is actually trying to use the app) would be the hardest part, as it would likely be different for each app. Also you can't just send the API a bunch of random shite. The API endpoint is looking for specific information and will ignore other information. The app would be very expensive to develop, I would imagine, and the minimal impact of the outcome probably isn't worth it.

quote:

---

For the most part, the payload of the request lives in the request body or URL and not in some hashed key, the API authorization token is found in the header.

---

I did not mean that the payload is sent in hashed form, by "incorporated" I meant that the payload is used to generate the hash found in the header.

quote:

---

The majority of APIs are setup to where you present authorization via the request header, and if valid, it lets you through to do what you want (ie a POST request with location data in the request body) or sends the information you requested. The key has nothing to do with how the payload is sent and the contents of the request body will not alter the validity of the auth token. Sure, request over HTTPS are encrypted because it's HTTPS but that doesn't mean you can't intercept requests and change their payload via proxy,

---

Look up MAC / HMAC tokens.

I guess my explanation is lacking because I did not mean to give the impression that the payload itself has to be obfuscated in any way in order to secure it from modification. As a simple example, you could hash the body contents and include that hash as a claim in your signed JWT. Now the server can verify that the body is exactly what the JWT says it should be. No one can change location data, for example, without generating a new JWT. And they can't do that without the key.

I believe AWS does something similar with some of their services.

We aren't talking about sensitive info, we are talking about location data provided to an API server. Open, in the clear, in the body of the request. The server just needs to make sure it hasn't been modified by a middle man. You can do that with a token in the request header.

The whole point of a JWT is to verify that the claims it makes are legit by verifying its signature. If I add a new custom claim to a JWT, the signature will change. If I add a claim that is a hash of the request body (which includes location data), the JWT signature will allow the server to know that the request body has not been modified by a middle man. You can't change the request body without changing the hash it produces, and you can't put this new hash in the JWT claims without signing it again, and you can't sign it again without the key. Make sense?


Edit: To clarify, this requires a shared key for symmetric signing.