API Security : SPA

Pradeep kumar R
Dec 19, 2018 · 2 min read

With the advent of today’s emerging trends, inorder to keep the customers engaged on public platforms with out registration but still run business ( with Guest option) might need extra security/precautionary measures if any client is sharing information publicly prone for bots. The not very good side of it that they only steal the data but the bad side of it is that there is enough potential to damage that the API and systems can’t recover from.

So how could we protect our API when accessed via any client? for example even SPA is just another client for an API. we can’t include tokens/secret in the SPA as its prone to exposure and anyone can easily sniff imposing as another client in the simplest form of curl or Postman; The attacker can create their own client to consume just by fake setting to default http-referer or default cross origin headers that we pass in SPA for access cross origin requests in general.

But we can consider to perform certain precautions that can keep our API’s safe with API Gateway.

In case of open endpoint with no user auth leverage API Gateway

1. Add Auth ( OAuth 2 Implicit grant type in case of SPA )

What it means is that we need to restrict our API usage with Auth mechanism & register all clients as consumers with a unique client Id and client secret. These unique credentials will help identify an API consumer by authorising each request via Authorization server. ( preferably with expiring token )

2. Apply policies like rate limiting, IP restriction

what it means is that we need to throttle requests to not allow bulk requests esp. in case of bot attacks.

On an average a typical user might access 1 record every 5 or 10 seconds, so it’s ideal to limit the rate beyond this.

if we could get by default the X-Forwarded-For (capturing the real ip address) then we can plan to limit API access by throttling and IP restriction ( all the API gateways provides this feasibility )

But we need to be cautious if in case we perform some regression and performance test internally and these policies shouldn’t block them and perhaps right way is to whitelist them.

Else the other option is to ensure user registration and enable user authentication in addition to API Auth for accessing API’s but still apply the rate limiting and IP restriction when we detect any anomaly in request rate.

Pradeep kumar R

Written by

Expertise in Designing Customer Centric Products

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade