Security for SPA

Introduction

APIs have arguably become the preferred method for building modern applications, especially for mobile and Internet of Things (IoT) devices. No matter how many APIs your organization chooses to share publicly, your ultimate goal should be to establish solid API security policies and manage them proactively overtime.

APIs are susceptible to many of the same kinds of attacks defenders have been fighting in their networks and web-based apps for years. None of the following attacks are newbut can easily be used against APIs.

• Injection occurs when an attacker is able to insert malicious code or commands into a program, usually where ordinary user input (such as a username or password) is expected. SQL injection is a specific type of injection attack, enabling an attacker to gain control of an SQL database.
• Cross-site scripting (XSS)is a type of injection attack that occurs when a vulnerability enables an attacker to insert a malicious script (often JavaScript) into the code of a web app or webpage.
• Distributed denial-of-service (DDoS) attacks make a network, system, or website unavailable to intended users, typically by flooding it with more traffic than it can handle. API endpoints are among the growing list of DDoS targets.
• Man-in-the-middle (MitM) attacks occur when an attacker intercepts traffic between two communicating systems and impersonates each to the other, acting as an invisible proxy between the two. With APIs, MitM attacks can occur between the client (app) andthe API, or between the API and its endpoint.
• Credential stuffing is the use stolen credentials on API authentication endpoints to gain unauthorizedaccess.

‍

‍

Grant Type Selection

‍

Authorization Code Grant

Authorization code grant is the current recommendation for browser – based applications and as these applications are public clients, PKCE must be implemented.

‍

Use of PKCE

PKCE introduces three new parameters to the authorization code grant flow, namely “code_verifier”, “code_challenge”and “code_challenge_method”. In the improved flow, before making the authorization redirect to the server, the application creates and stores as secret named “code_verifier”. Then it hashes “code_verifier” and gets the“code_challenge” from it . This “code_challenge” and code_challenge_methodarepassed along with other authorization request attributes to the authorization server.

After receiving the authorization code, the application includes the “code_verifier” attribute in the token request made to the authorization server. The authorization server will verify the“code_verifier” with previously stored “code_challenge” and“code_challenge_method” before issuing the access token.

An attacker who intercepts the authorization code is unable to redeem it for an access token, as they are not in possession of the“code_verifier” secret.

‍

Use of state parameter

SPAs need to use the state parameter to protect themselves against cross site request forgery and authorization code swap attacks and must use a unique value for each authorization request.                            

‍

Refresh Tokens

Refresh tokens provide a way to get a new access token when the access token expires,without the involvement of the end user. For an SPA, this will help to improve the user experience by avoiding redirections when the access token expires.

• The authorization server should issue a new refresh token with every access token refresh response. This will help to identify and avoid replay attacks and during detection of such an attack, the authorization server must revoke all tokens issued as it is not possible to identify whether the legitimate user or attacker has the valid access token.
• Having a limited validity period for a refresh token will help to identify any token leakage sooner.

‍

Securely store tokens

In a web browser, there are multiple options to store tokens. You can store them in cookies, or you can store the min HTML5 storage. Or you can save them in browser memory.Cookies will be the least secure option among the three as it is vulnerable to both cross site scripting(XSS) attacks and cross site request forgery (CSRF) attacks. We have a browser memory option, which is a solution built using the web workers and it is considered the most secure option.

Conclusion:

• Stop using HTTP, even during development. UseHTTPS.
• CORS Allow all? Of course NOT! Never allow everything in CORS, except you are creating an extremely public API. During development, you might have to allow one or more addresses when runningback-end and front-end separately.