Security Policies
To ensure the security of our API structure and capabilities, it is essential to implement robust security practices that maintain the integrity and confidentiality of the data made available through our APIs.
Authentication and Authorization (e.g., OAuth 2.0, JWT)
All requests to our API services must (MUST) include authentication information that verifies the identity of the requester if the endpoint handles sensitive, non-public, or user-specific data. Supported methods such as OAuth 2.0 or JWT (JSON Web Tokens) should be used to provide secure and flexible authentication. The API Gateway, as the first level of authorization, ensures that users can only access resources for which they have permissions and defines the method of authorization.
Example:
Authorization: Bearer [token]
Usernames, passwords, session tokens, API keys, and other sensitive information MUST NOT appear in the URL. Such information could be captured in web server logs, making them particularly vulnerable to misuse.
Data Encryption (TLS/SSL)
All communication between clients and the API Gateway must (MUST) be conducted over HTTPS to ensure data integrity and confidentiality. The use of TLS/SSL encryption for all data transmissions is mandatory.
CORS (Cross-Origin Resource Sharing)
When API resources receive requests from a domain other than their own, Cross-Origin Resource Sharing (CORS) must (MUST) be enabled for selected methods on the resource. This requires the API to respond to the OPTIONS preflight request with at least the following CORS headers:
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Allow-Origin
CORS policies should (SHOULD) be configured to control which domains are allowed to send requests to the API Gateway and services. This is particularly important to prevent Cross-Site Scripting (XSS) and data leaks. CORS headers are also required when using JavaScript or native mobile SDKs.
Rate Limiting and Throttling
The API Gateway must (MUST) implement rate limiting and throttling to prevent DoS (Denial of Service) attacks and other abusive usage. Limits should be set based on user identification and usage patterns per resource. These limits must be documented, and specific restrictive headers should be passed from the underlying services to the gateway.
Example for Rate Limiting Header:
X-Rate-Limit-Limit: 1000
X-Rate-Limit-Remaining: 998
X-Rate-Limit-Reset: 3600