Solved: Single Page Application with anonymous users

manimanavalan · 05-30-2020 07:37 PM

HI,

What is the best security option for SPA used by anonymous users?

Requirement is to protect commercial ref application ( stores documents, images) which has following API call sequence.

Anonymous users --> SPA(public) --> APIGEE(SaaS) --> Commercial ref application(Internal)

Note: Enterprise uses external IDP with OAuth grant types when SPA + Authenticated users involved.

dchiesa1

The best Security approach is multi-layered . Some people call it "defense in depth."

You will want to use a combination of tools and strategies in order to protect your internal systems.

Spike Arrest. This protects internal systems from malicious or inadvertent spikes in requests coming from the API layer. The "Commercial ref application" may not be designed to scale to a sudden spike, or you may not wish to subject that system to arbitrary inbound load. So use a Spike Arrest policy to restrict it to 100 requests per second, or whatever you deem appropriate. Apigee will enforce this limit irrespective of the authentication of the API user.
Bot mitigation. You can use a system like reCAPTCHA v3 or some other scoring/evaluation system for determining whether a client is a bot, or an officially sanctioned app (like the SPA on your .com site). Calling out to reCAPTCHA v3 from Apigee is straightforward using ServiceCallout. There are also WAF approaches like Akamai, Google Cloud Armor, or Imperva.
Rate limiting - you can enforce rate limiting at the API layer for your SPA. The way this might work: Each SPA instance being used by an anonymous user might get a "anonymous token" from Apigee, and you can use that token to rate limit with the Quota policy. For example, allow no more than 25 queries per minute per token.
You can also build natural client-enforced rated limiting with things like Hashcash or Merkle Tree. These require the client to perform some expensive work, which can be easily verified by the Apigee proxy. Each new request might require a new proof-of-work.

dchiesa1

The best Security approach is multi-layered . Some people call it "defense in depth."

You will want to use a combination of tools and strategies in order to protect your internal systems.

Spike Arrest. This protects internal systems from malicious or inadvertent spikes in requests coming from the API layer. The "Commercial ref application" may not be designed to scale to a sudden spike, or you may not wish to subject that system to arbitrary inbound load. So use a Spike Arrest policy to restrict it to 100 requests per second, or whatever you deem appropriate. Apigee will enforce this limit irrespective of the authentication of the API user.
Bot mitigation. You can use a system like reCAPTCHA v3 or some other scoring/evaluation system for determining whether a client is a bot, or an officially sanctioned app (like the SPA on your .com site). Calling out to reCAPTCHA v3 from Apigee is straightforward using ServiceCallout. There are also WAF approaches like Akamai, Google Cloud Armor, or Imperva.
Rate limiting - you can enforce rate limiting at the API layer for your SPA. The way this might work: Each SPA instance being used by an anonymous user might get a "anonymous token" from Apigee, and you can use that token to rate limit with the Quota policy. For example, allow no more than 25 queries per minute per token.
You can also build natural client-enforced rated limiting with things like Hashcash or Merkle Tree. These require the client to perform some expensive work, which can be easily verified by the Apigee proxy. Each new request might require a new proof-of-work.