| Follow standard frameworks for authorization | Leverage open standard frameworks such as OAuth for authorization that controls authorization to protected resources like applications or groups of files |
| Implement API gateway , implement default deny | Implement API gateways. This helps enforce policies which control security aspects such as the authentication, authorization or traffic management |
| Validate all API calls made by an user for object level access | Application Server should validate the incoming API calls and determine if the user has the permissions to execute those calls |
| Implement secrets management for API keys | Leverage secrets management for the API keys being used |
| Only specific target audience should have API key access | Configure different permissions for different API Keys |
| Leverage authentication framework | Leverage standards and frameworks like OpenID Connect, OAuth2, JWT, Spring Security, AWS Cognito, Okta etc., for authentication purpose |
| Access tokens should be issued only for required claims | If access tokens are used then as a best practice it should be ensured that tokens are issued for only the required claims. |
| Usage of encrypted communication | Always use TLS which encrypts API data during transit |
| User session should be properly terminated | The session should terminate once the user logs out |
| Account lockout should be implemented | The user should be locked out when multiple API authentication requests are sent. |
| Strong session handling mechanisms should be implemented | The session token should be randomized for every login. Session handling mechanism should be implemented between client & server |
| Secure the JWT tokens | Do not accept unsigned/weakly signed JWT tokens (“alg”:”none”)/doesn’t validate their expiration date |
| Implement Multifactor Authentication | Where possible, implement MFA for extra layer of security |
| Enable IP whitelisting for authorized parties | Enable whitelisting of IP address to allow only authorized parties who have access to make calls to the API endpoints |
| Prevent exposing sensitive information | The API calls should not disclose any sensitive information which can be leveraged for further targeted attacks |
| API segreggation should be implemented | APIs should be segregated based on the sensitivity of the data |
| Error responses should not have any sensitive information disclosed | API error response should be sanitized for sensitive environment/server related information. |
| Implement Schema based validation | Implement a schema-based request validation mechanism as an extra layer of security |
| Implement data size restrictions | Where possible, define a payload max length and a maximum size of data for all incoming parameters |
| Implement Rate limiting on API requests made | Implement Rate Limiting on the API calls and throttle the requests. This can help prevent DOS attacks on APIs |
| Check for funtion level authorization | Always implement function-level authorization checks for an API request for a function. |
| Implement principle of least priviledge for API endpoints | Based on the user roles, the users should have access only to a certain limit of API endpoints rather than the entire set. |
| Implement RBAC for sensitive APIs | APIs involving sensitive PII information should have the correct access controls and seggregation between administrative and regular user roles should be defined. |
| Do not allow access to old API versions | Always protect your old API versions. Do not allow access to unused API version such as /api/v1 when a new version /api/v2 is released. |
| Control the usage of sensitive functions and properties of API objects | Avoid using functions or sensitive properties (eg: Permission that automatically bind a client’s input into code variables or internal objects |
| – Headers should be secured | The user tokens should be properly protected with the right headers. |
| Allow only specific HTTP Verbs | Ensure API can only be accessed by the specified HTTP verbs. All other HTTP verbs should be disabled. APIs should adhere with HTTP standards (Eg: GET operation should not update the system, similarly POST and PUT should be used to create and update entities ) |
| Data in Transit should be secured via encrypted channels | API calls should be made only via encrypted channel. Always use HTTPS for communication |
| Enable CORS settings wherever required | APIs should start with restrictive CORS settings and relax the setting on need basis. And APIs expecting to be accessed from browser-based clients (e.g., WebApp front-end) should implement a proper Cross-Origin Resource Sharing (CORS) policy |
| API – Injection – Perform input validation for API requests. | Always consider user inputs as malicious and validate them for every call. Filter, sanitize, encode all the user inputs to prevent injection based attacks |
| API – Injection – Control the data types used in application API parameters | Define data types and strict patterns for all string parameters |
| API – Injection – Implement random values for sensitive fields such as record IDs, user IDs etc | Prefer to use random and unpredictable values such as GUIDs (for example) for records’ IDs |
| API – ILM – Authentication logging should be enabled | Log all failed authentication attempts, denied access, and input validation errors. |
| Audit trail should be maintained | It is recommended to maintain a logging of the user action. Maintaining an audit trial will help in tracking the malicious events when they occur. |
| Integrate with SIEM if needed | Use a Security Information and Event Management (SIEM) system to aggregate and manage logs from all components of the API stack and hosts. |
| Object Identifiers are not easily guessable. | If the endpoint takes in object identifier as the input then make sure that identifier is not easily guessable. Try to use UUID as a identifier instead of alphumeric sequence. |
| Validate that the Get,Head ,Options endpoints do NOT modify existing entities or add new entities. | Make sure that the HTTP Get calls are not inserting or updating the data. Sometimes Get implementation the code updates the record or inserts new entities that violates the http Get symantics |
| Create inventory of the API with host , access level , data flow , error responses , request-response etc. | Self explanatory |
| Make sure the documentation, inventory is available to only authorized users. | Self explanatory |
| If Saas proider is involved then validate the securith posture of Saas providers and make sure Saas providers have gone through TPO process. | Self explanatory |
| Make sure api is only accessible over secure channel TLS | The https TLS 1.3 should be used as the channel |
| UASBF – Recommended to use IP Whitelisting for specific client users as and when required. | If the API endpoint is exposed outside and is part of sensitive business flow the IP whitelisting should be in place |
| SSF – Validate all user Input specifically if input contains any user supplied resource location. | If the resources like (images / icons / files etc.) are loaded from the input from untrusted source. The resource location should be validated. |
| SSF -Use secure url parsers and disbale unsafe schemas , for example – like file, dict,ftp,goffer. | If the resources like (images / icons / files etc.) are loaded from the input from untrusted source. The resource location should be validated. Unsafe schemas should be disabled and locations like localhost etc. |