Building Secure APIs
Ready for review
Design Principles
API designers/developers MUST consider the OWASP Security By Design Principles and document how these are implemented by their API.
| Check | OWASP Security By Design Principle | Summary statement |
|---|---|---|
| ▢ | Minimize attack surface area | Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface area. |
| ▢ | Establish secure defaults | However, by default, the experience should be secure, and it should be up to the user to reduce their security – if they are allowed. |
| ▢ | Principle of Least privilege | Accounts shall have the minimum privileges required to perform their business processes |
| ▢ | Principle of Defense in depth | Where one control would be reasonable, more controls that approach risks in different fashions are better. |
| ▢ | Fail securely | Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not. |
| ▢ | Don’t trust services | Do not implicitly trust services/functions supplied from outside the API application boundary |
| ▢ | Separation of duties | Administrators should not be users of the application and vice versa |
| ▢ | Avoid security by obscurity | Security through obscurity is a weak security control, and nearly always fails when it is the only control. |
| ▢ | Keep security simple | Favour straightforward and simple code over overly complex approaches |
| ▢ | Fix security issues correctly | Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. |
General technical security requirements
API designers/developers MUST ensure the API implementation adheres to all of the following best practices:
| Check | Requirement | Description |
|---|---|---|
| ▢ | Encryption of data in transit | All communication between client application and the OAuth 2 / OpenID Connect server MUST be over TLS to help address eavesdropping and man in the middle attacks. |
| ▢ | Validate all incoming data | All content of all incoming messages MUST be validated by the API implementation and/or its supporting infrastructure |
| ▢ | Forbidden OAuth grant types | APIs MUST NOT allow use of OAuth Implicit or Password Grant Types. |
| ▢ | Validate REDIRECTs | OAuth 2.0-protected API servers MUST check the redirect_uri of received authorisation requests is identical to the redirection URI registered for the client (consumer), to mitigate redirection to unauthorised URIs. |
| ▢ | Validate OAuth ID tokens | Consumers of OAuth-secured1 APIs MUST validate OAuth ID tokens they obtain from an OAuth authorization server. |
| ▢ | Validate OAuth Access tokens | Consumers of OAuth-secured APIs MUST validate Issuer, Signature, Claims and Scopes in an OAuth Access token before use. |
| ▢ | OAuth tokens to be short-lived | APIs which require OAuth 2.0/2.1 tokens MUST ensure each token is issued with a short2 lifetime / expiry, to minimise risks from use of stolen tokens. When long access periods are required, the API MUST require the use of Refresh Tokens |
| ▢ | Request minimal OAuth scopes | In line with the least privilege design principle, OAuth 2.0/2.1 API consumers SHOULD request only scopes needed for a particular solution domain and context of usage |
| ▢ | Tokens stored encrypted | If an OAuth-protected API Consumer needs to store a token, this MUST only be done in encrypted local storage |
| ▢ | Proof Key for Code Exchange (PKCE) | OAuth 2.0/2.1 API consumers SHOULD use PKCE (pronounced "pixie") to prevent cross site request forgery and authorization code injection attacks |
Reference Resources
The following resources are recommended reading for those who are new to API implementation.
-
Design Driven Development (refer to Part C)
-
OWASP Top Ten – A summary of the standard attacks and mitigations
-
REST Security Cheat Sheet – REST-specific risks and how to prevent them, e.g. input validation
-
OWASP API Security Project – Top 10 API-specific risks and how to prevent them
The OWASP Cheat Sheet Series provides cheat sheets on a variety of security-related subjects. It is worth reviewing them to see if others may apply to your specific circumstances. Special note should be taken of the following where your API accepts input values as parameters:
-
OWASP Input Validation Cheat Sheet – A summary of input risks and mitigations
-
OWASP Cross Site Scripting Prevention Cheat Sheet – how to escape inputs to prevent cross site scripting
-
OWASP SQL Injection Prevention Cheat Sheet – ensuring database queries are built internally
-
OWASP Query Parameterization Cheat Sheet – examples of SQL injection and stored procedure vulnerabilities