Content
1. Exposing API Keys and Sensitive Credentials
API keys, access tokens, and database credentials help applications authenticate with services. However, storing these secrets directly in source code, public repositories, frontend JavaScript, or unsecured configuration files can expose them to attackers.
Once an attacker obtains a valid API key, they may use it to access restricted services, consume paid resources, or retrieve sensitive information.
How to prevent it:
Store sensitive credentials in environment variables or a secure secrets management system.
Never commit API keys or passwords to public repositories.
Rotate compromised credentials immediately and regularly review access permissions.
Use separate credentials for development, testing, and production environments.
Developers should also remember that secrets embedded in frontend applications cannot be kept confidential. Any credential that must remain private should be protected on the server side.
2. Implementing Broken Access Controls
Authentication verifies who a user is, while authorization determines what that user can access. An API may authenticate users correctly but still expose sensitive resources if authorization checks are missing or improperly implemented.
For example, an attacker might change an account ID in an API request to retrieve another customer's profile or transaction history. This type of vulnerability is commonly associated with broken object-level authorization.
How to prevent it:
Verify permissions on every request involving protected resources.
Enforce object-level and function-level authorization on the server.
Apply the principle of least privilege.
Test whether users can access resources belonging to other accounts.
Never assume that a user is authorized simply because they possess a valid token or know a resource identifier.
3. Failing to Implement Rate Limiting
Without rate limiting, attackers can send excessive requests to an API, potentially causing service disruptions, increasing infrastructure costs, or attempting to guess passwords and verification codes.
For example, an authentication endpoint without request limits may allow automated tools to perform thousands of login attempts.
How to prevent it:
Apply rate limits to login, registration, password recovery, and other sensitive endpoints.
Set limits based on user identity, API keys, IP addresses, or other appropriate signals.
Return HTTP 429 (Too Many Requests) when a client exceeds its permitted request rate.
Use additional protections, such as progressive delays and abuse detection, where appropriate.
Rate limits should reflect the purpose of each endpoint. Combining them with monitoring and alerting helps developers identify suspicious activity before it causes significant damage.
4. Exposing Excessive Data Through API Responses
An API can unintentionally reveal sensitive information when it returns more data than the client actually needs. For instance, a profile endpoint might expose internal user identifiers, administrative flags, password-reset metadata, or other confidential fields.
Even when some information is not immediately exploitable, unnecessary exposure can help attackers plan further attacks.
How to prevent it:
Return only the fields required by the client.
Use explicit response schemas or data transfer objects (DTOs).
Exclude passwords, secret tokens, internal configuration, and sensitive personal information.
Review API responses during security testing.
Data minimization is an important API security best practice because reducing exposed information also reduces the potential impact of a breach.
5. Using Weak Input Validation
APIs frequently accept user input through query parameters, request bodies, headers, and URL paths. If this input is not validated correctly, attackers may exploit injection vulnerabilities, manipulate application logic, or submit unexpected values that cause errors.
For example, an API that builds database queries by concatenating untrusted input may be vulnerable to SQL injection.
How to prevent it:
Validate incoming data against clearly defined schemas.
Enforce expected data types, lengths, formats, and permitted values.
Use parameterized database queries rather than constructing SQL statements from raw input.
Apply context-appropriate output encoding and safe parsing practices.
Reject malformed or unexpected requests.
Input validation should happen on the server, even when frontend validation is already implemented. Client-side checks improve usability but cannot serve as the primary security control.
6. Returning Detailed Error Messages
Detailed error messages can help developers troubleshoot problems, but exposing internal stack traces, database errors, file paths, or configuration details to API consumers can give attackers valuable information about the application.
For example, a database error might reveal table names or query structure that an attacker could use to develop a more targeted attack.
How to prevent it:
Return clear, generic error messages to external clients.
Use appropriate HTTP status codes, such as 400 for invalid requests, 401 for unauthenticated requests, and 403 for forbidden operations.
Record detailed diagnostic information in protected server-side logs.
Never expose passwords, access tokens, or other secrets in error responses or logs.
Effective error handling balances usability with security by providing enough information to resolve client-side problems without revealing sensitive implementation details.
7. Neglecting API Security Testing and Monitoring
API security is not a one-time task. New endpoints, changing business requirements, software dependencies, and configuration updates can introduce vulnerabilities after an application has been deployed.
Developers who skip security testing or fail to monitor API activity may overlook weaknesses until attackers exploit them.
How to prevent it:
Include security testing in continuous integration and deployment pipelines.
Perform regular vulnerability assessments and penetration tests.
Use automated tools to detect vulnerable dependencies and common API flaws.
Monitor authentication failures, unusual traffic patterns, and suspicious access attempts.
Review API inventories and retire unused or deprecated endpoints.
A proactive security strategy combines automated testing, manual verification, monitoring, and regular updates to help maintain API security throughout the application's lifecycle.
API keys, access tokens, and database credentials help applications authenticate with services. However, storing these secrets directly in source code, public repositories, frontend JavaScript, or unsecured configuration files can expose them to attackers.
Once an attacker obtains a valid API key, they may use it to access restricted services, consume paid resources, or retrieve sensitive information.
How to prevent it:
Store sensitive credentials in environment variables or a secure secrets management system.
Never commit API keys or passwords to public repositories.
Rotate compromised credentials immediately and regularly review access permissions.
Use separate credentials for development, testing, and production environments.
Developers should also remember that secrets embedded in frontend applications cannot be kept confidential. Any credential that must remain private should be protected on the server side.
2. Implementing Broken Access Controls
Authentication verifies who a user is, while authorization determines what that user can access. An API may authenticate users correctly but still expose sensitive resources if authorization checks are missing or improperly implemented.
For example, an attacker might change an account ID in an API request to retrieve another customer's profile or transaction history. This type of vulnerability is commonly associated with broken object-level authorization.
How to prevent it:
Verify permissions on every request involving protected resources.
Enforce object-level and function-level authorization on the server.
Apply the principle of least privilege.
Test whether users can access resources belonging to other accounts.
Never assume that a user is authorized simply because they possess a valid token or know a resource identifier.
3. Failing to Implement Rate Limiting
Without rate limiting, attackers can send excessive requests to an API, potentially causing service disruptions, increasing infrastructure costs, or attempting to guess passwords and verification codes.
For example, an authentication endpoint without request limits may allow automated tools to perform thousands of login attempts.
How to prevent it:
Apply rate limits to login, registration, password recovery, and other sensitive endpoints.
Set limits based on user identity, API keys, IP addresses, or other appropriate signals.
Return HTTP 429 (Too Many Requests) when a client exceeds its permitted request rate.
Use additional protections, such as progressive delays and abuse detection, where appropriate.
Rate limits should reflect the purpose of each endpoint. Combining them with monitoring and alerting helps developers identify suspicious activity before it causes significant damage.
4. Exposing Excessive Data Through API Responses
An API can unintentionally reveal sensitive information when it returns more data than the client actually needs. For instance, a profile endpoint might expose internal user identifiers, administrative flags, password-reset metadata, or other confidential fields.
Even when some information is not immediately exploitable, unnecessary exposure can help attackers plan further attacks.
How to prevent it:
Return only the fields required by the client.
Use explicit response schemas or data transfer objects (DTOs).
Exclude passwords, secret tokens, internal configuration, and sensitive personal information.
Review API responses during security testing.
Data minimization is an important API security best practice because reducing exposed information also reduces the potential impact of a breach.
5. Using Weak Input Validation
APIs frequently accept user input through query parameters, request bodies, headers, and URL paths. If this input is not validated correctly, attackers may exploit injection vulnerabilities, manipulate application logic, or submit unexpected values that cause errors.
For example, an API that builds database queries by concatenating untrusted input may be vulnerable to SQL injection.
How to prevent it:
Validate incoming data against clearly defined schemas.
Enforce expected data types, lengths, formats, and permitted values.
Use parameterized database queries rather than constructing SQL statements from raw input.
Apply context-appropriate output encoding and safe parsing practices.
Reject malformed or unexpected requests.
Input validation should happen on the server, even when frontend validation is already implemented. Client-side checks improve usability but cannot serve as the primary security control.
6. Returning Detailed Error Messages
Detailed error messages can help developers troubleshoot problems, but exposing internal stack traces, database errors, file paths, or configuration details to API consumers can give attackers valuable information about the application.
For example, a database error might reveal table names or query structure that an attacker could use to develop a more targeted attack.
How to prevent it:
Return clear, generic error messages to external clients.
Use appropriate HTTP status codes, such as 400 for invalid requests, 401 for unauthenticated requests, and 403 for forbidden operations.
Record detailed diagnostic information in protected server-side logs.
Never expose passwords, access tokens, or other secrets in error responses or logs.
Effective error handling balances usability with security by providing enough information to resolve client-side problems without revealing sensitive implementation details.
7. Neglecting API Security Testing and Monitoring
API security is not a one-time task. New endpoints, changing business requirements, software dependencies, and configuration updates can introduce vulnerabilities after an application has been deployed.
Developers who skip security testing or fail to monitor API activity may overlook weaknesses until attackers exploit them.
How to prevent it:
Include security testing in continuous integration and deployment pipelines.
Perform regular vulnerability assessments and penetration tests.
Use automated tools to detect vulnerable dependencies and common API flaws.
Monitor authentication failures, unusual traffic patterns, and suspicious access attempts.
Review API inventories and retire unused or deprecated endpoints.
A proactive security strategy combines automated testing, manual verification, monitoring, and regular updates to help maintain API security throughout the application's lifecycle.