1

So I have a web page running a JavaScript application, and a web service that the application makes HTTP PUT requests against. The service uses access tokens to verify the user’s identity, but now I’m scratching my head about how to prevent authorized users from using the API inappropriately. I.e. what’s to stop a malicious user from simply inspecting outgoing traffic in their browser, copying the service url and their access token, and using it to spam calls against the service?

Is there a standard way of preventing this sort of misuse? I thought I'd be able to hide or encrypt the user's tokens so they can't see them, but it doesn't seem like that's possible.

Cheers!

0

I.e. what’s to stop a malicious user from simply inspecting outgoing traffic in their browser, copying the service url and their access token, and using it to spam calls against the service?

Nothing. A user has full control over the client application. You can't stop them from extracting the token, modifying the JS code or just building their own custom client. Even if you heavily obfuscate the code, they can eventually capture the requests to the API and replay them later.

Is there a standard way of preventing this sort of misuse?

The common way to protect APIs from abuse is rate limiting. E.g., you can limit the allowed number of requests per user for a certain time frame or establish limits based on IP addresses. However, you can't prevent them from using the API from outside your app.

Also see:

0

The standard way is to to "reproxy" the outside API call through your server. This is also used to provide non-CORS API integration, hide secret API keys, allowing service provider changes without refactoring client code, as well as security.

Since all the calls now go through your server, you can honor or decline them as needed, based on authentication, rate limiting, or practically any other type of rule you can dream up and code.

You can also implement app tokens and sync allowances so that only your app can make use of the "new" API you're (re)serving. Without re-proxying, you have to rely on user honesty and legalese.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.