Deep Diving into API Security

Summary

The most common threats to APIs

Injection Attacks

In these attacks, attackers inject malicious code into API requests, often through insufficiently checked input in headers, cookies, or message texts. Well-known examples include SQL injection and command injection. Consequences include data leaks, system compromise, and unauthorized access.

Cross-Site Scripting (XSS)

In this attack, malicious scripts are injected into web applications to manipulate API requests in another user's browser. This is usually caused by a lack of data cleansing. Possible consequences include: Data theft, session hijacking, and manipulation of user actions.

Distributed Denial-of-Service (DDoS) Attacks

DDoS attacks flood APIs with requests, rendering services inaccessible to legitimate users. Rate limits or protection mechanisms are often missing. Consequences include downtime, increased costs, and reputational damage.

Man-in-the-Middle (MitM) Attacks

In these attacks, attackers intercept communication between the client and API server due to a lack of encryption. Their aim is to read or manipulate sensitive data, such as access credentials or API keys.

API Abuse

Legitimate API functions are used maliciously, for example, through mass data retrieval or overloading. This is caused by a lack of rate limits and unclear usage specifications. Consequences include service interruptions, resource exhaustion, and data misuse.

Common vulnerabilities of APIs

Broken Object Level Authorization (BOLA)

Inadequate or missing authorization checks at the object level allow attackers to access or alter third-party data by manipulating IDs. Consequences: Unauthorized access, data manipulation, and data breaches.

Broken User Authentication

Weak or faulty authentication mechanisms allow attackers to impersonate other users, for example, by using weak passwords, insecure tokens, or failing to implement multi-factor authentication. Consequences include compromised accounts, data misuse, and loss of trust.

Broken Function Level Authorization

Insufficient access controls at the function level allow attackers to perform functions not assigned to their role, such as administrative actions. Consequences include expanded rights, system manipulation, and loss of data.

Improper Asset Management

A lack of oversight and control over all APIs means that outdated or forgotten interfaces remain unprotected. Consequences: Unauthorized access to sensitive data via "ghost APIs."

Excessive Data Exposure

APIs often reveal more data than necessary for their function because they rely on client-side filtering. Consequence: Disclosure of sensitive information and increased attack surface.

Lack of Resources & Rate Limiting

Failing to limit requests or resources makes APIs susceptible to overload and misuse, e.g., through DDoS or brute force attacks. Consequences include outages, performance problems, and cost increases.

Mass Assignment

APIs allow unwanted fields to be manipulated when updating resources if the permitted parameters are not strictly controlled. Consequences include rights escalation and manipulation of sensitive fields.

Injection

Insufficient validation allows malicious code, such as SQL or command injection, to be injected into API requests. Consequences include data loss, system compromise, and unauthorized access.

Insufficient Authentication & Session Management

Incorrect management of authentication and sessions (e.g., insecure tokens or missing invalidation) enables attackers to take over third-party accounts or perform actions on behalf of other users. Consequences include data misuse, loss of control, and reputational damage.

Best practices for protecting APIs

Basic Security Principles

Organisational measures

• Establish a culture of security within your team and organisation. Make developers and other stakeholders aware of the importance of API security and train them regularly in secure development practices.
• Define clear security policies and processes for developing, deploying and maintaining APIs. This includes, for example, policies on password assignment, handling API keys and responding to security incidents.
• Maintain a comprehensive inventory of your APIs and associated resources. You can only protect what you know.
• Ensure that API security responsibilities and accountabilities are clearly defined.
• Consider compliance requirements such as GDPR, HIPAA or PCI DSS from the start of the development process.

Technical measures

• Consider security when planning and designing your APIs (security by design).
• Never trust the data sent by clients (zero trust policy).
• Apply the principle of least privilege at the system level, for example by giving API applications only the minimum privileges needed to access databases or other resources.
• Use HTTPS (TLS/SSL) for all communication with the API.
• Implement comprehensive logging and monitoring of API calls to detect suspicious activity and respond in the event of a security incident. Ensure that sensitive data is not exposed in the logs.
• Implement secure error handling that does not reveal unnecessary details about the internal workings of the API. Return generic error messages to the client and log detailed errors internally.
• Perform code reviews where security experts check the code for potential vulnerabilities.
• Automate security testing in your CI/CD pipeline to ensure that security aspects are continuously checked.
• Conduct regular security audits and penetration tests to identify and remediate vulnerabilities early. Use API security tools to automate and support this process.
• Stay aware of the constantly evolving threat landscape and continuously adapt your security measures to new risks.

Implementing strong Authentication Mechanisms

Organisational measures

• Define clear authentication policies, including acceptable authentication methods, minimum credential requirements (if applicable), and frequency of password changes.
• Train your developers in the basics of secure authentication practices and the risks of weak authentication methods.
• Conduct regular reviews of implemented authentication mechanisms to ensure they continue to meet current security standards.

Technical measures

• Where possible, use proven and standardised authentication protocols such as OpenID Connect.
• Implement secure credential management and storage practices (e.g. secure password hashing with Salt).
• Consider implementing multi-factor authentication (MFA) for critical API endpoints or user accounts with elevated privileges.
• Use API keys only as a supplemental or basic form of authentication, not as the sole security measure for sensitive operations. API keys should be securely generated, transmitted and stored.
• Protect against brute force attacks on credentials with measures such as limiting the number of failed login attempts and temporary account lockouts.
• Rely on token-based authentication using JSON Web Tokens (JWT). JWTs are self-describing, lightweight, and enable stateless authentication. Ensure that strong cryptographic algorithms are used to sign tokens.
• Ensure that session tokens are securely generated, transmitted (e.g. as HTTP-only cookies over HTTPS) and managed on the server side. Invalidate session tokens after the user logs out and set appropriate session expiration times.

Implementation notes

• Integrate authentication logic into security-relevant layers of your application, not directly into the API endpoints. For example, use middleware or filters to perform authentication before the request is actually processed.
• Use established libraries and frameworks to implement authentication protocols, rather than developing your own, potentially flawed solutions.
• Ensure that each API call is authenticated and that authentication information is verified for each request.
• Avoid sending sensitive authentication information in the URL. Instead, use HTTP headers or the request body (for POST requests).
• Implement secure logout functionality that terminates the user's current session and invalidates any associated tokens.
• Perform extensive testing of the implemented authentication mechanisms to ensure that they work correctly and do not contain any vulnerabilities.
• Log authentication attempts (both successful and failed) for monitoring and analysis purposes without revealing sensitive information.

Implementing fine-grained Authorisation

Organisational measures

• Define clear roles and responsibilities within your organisation and assign specific permissions to those roles to access API resources and functionality.
• Create a detailed permissions model that accurately describes the different levels of access and associated actions. This model should be regularly reviewed and adapted to changing requirements.
• Implement processes for granting and revoking privileges to ensure that users are only granted the privileges they currently need, and that privileges that are no longer required are removed in a timely manner.
• Conduct regular audits of access rights to ensure that they have been assigned correctly and according to defined policies.

Technical measures

• Implement mechanisms to enforce defined permissions on all relevant API endpoints and for all security-critical operations. This can be done through Role-Based Access Control (RBAC), where permissions are tied to roles, or Attribute-Based Access Control (ABAC), where access is decided based on attributes of the user, resource and context.
• Use claims within JWTs or other security tokens to transport the user's permissions. These claims can then be checked on the server side to make access control decisions.
• Ensure that the authorisation check occurs after authentication and before the requested action is performed.
• Avoid implicit authorisation, where access is assumed solely on the basis of authentication or the existence of an object. Instead, perform explicit authorisation checks.
• Consider function-level authorisation. Ensure that users can only access the functions they are authorised to use, especially for sensitive operations.
• Implement security measures against Broken Object Level Authorisation (BOLA). Ensure that users can only access the data objects for which they are authorised, even if they know the object ID. Check the access permission for each object accessed by a user ID.
• Consider Broken Object Property Level Authorization. Restrict access to individual attributes or properties of data objects to avoid excessive data exposure.

Implementation notes

• Integrate authorisation logic into your back-end services and don't just rely on client-side controls.
• Use centralised authorisation policy enforcement mechanisms to ensure consistency and maintainability.
• Thoroughly test authorisation mechanisms to ensure that they work correctly and that there are no unwanted access options. Write unit and integration tests for different authorisation scenarios.
• Log authorisation decisions (especially denied access attempts) for monitoring and analysis.
• Simplify complex access control policies to minimise the risk of misconfiguration and broken function level authorisation.
• Consistently apply the principle of least privilege, granting users and applications only the privileges they need to do their jobs.
• Be careful when implementing mass assignment and ensure that users can only update the fields for which they are authorised. Implement strict controls and validations for incoming data.

Data Encryption

Organisational measures

• Define clear policies for encrypting sensitive data, both in transit and at rest. Determine what data is considered sensitive and therefore must be encrypted.
• Train your developers in encryption technologies and key management best practices. Make them aware of the risks of unencrypted data.
• Conduct regular reviews of the encryption mechanisms and key management processes in place to ensure they remain effective and secure.
• Consider compliance requirements such as GDPR, HIPAA or PCI DSS, which may have specific requirements for encrypting personal or financial data.

Technical measures

• Use HTTPS (TLS/SSL) for all communication with the API to encrypt data in transit and protect against man-in-the-middle attacks. Ensure that up-to-date and secure versions of TLS (at least TLS 1.2) are used.
• Encrypt sensitive data at rest (e.g. in databases, file systems or log files) using strong cryptographic algorithms such as AES.
• Use secure key generation, storage and management practices. Key management is critical because the security of the encrypted data depends directly on the security of the keys used. Avoid storing keys in code.
• Consider using homomorphic encryption or other advanced encryption techniques for specific use cases where data needs to be processed without decryption.

Implementation notes

• Encrypt sensitive data as early as possible in the process and decrypt it as late as necessary.
• Use established and well-tested encryption libraries and frameworks rather than developing your own encryption algorithms.
• Ensure that all endpoints that send or receive sensitive data use HTTPS. Enforce HTTPS and redirect HTTP requests accordingly.
• Regularly review the configuration of your TLS/SSL implementation to ensure that there are no known vulnerabilities (e.g. by using appropriate cipher suites).
• Consider the performance impact of encryption and optimise your implementation accordingly.
• Perform tests to ensure that encryption and decryption work correctly and that data is effectively protected.
• Log the use of encryption mechanisms for auditing purposes without exposing sensitive keys.

Input Validation and Sanitisation

Organisational measures

• Define clear and detailed specifications for all expected input data from your API endpoints. Document the required formats, data types, length constraints, and permitted value ranges.
• Train your developers on the principles of secure input processing and the common attack vectors that are enabled by inadequate validation and sanitising.
• Implement policies and processes for reviewing and updating input validation rules to keep pace with changing requirements and potential new threats.
• Conduct regular code reviews with a particular focus on the correct implementation of input validation and sanitising.

Technical measures

• Always perform server-side input validation. Don't rely on client-side validation alone, as it can be easily bypassed.
• Use strict validation rules (allow-listing), where you explicitly define which inputs are allowed, rather than trying to block all possible invalid inputs (denying).
• Validate all types of input, including parameters in the URL, headers, cookies and the body of the request. Also consider the structure of data formats such as JSON or XML.
• Clean up input data by removing or rendering harmless potentially malicious characters or scripts (e.g. by encoding or escaping). Be careful with automatic cleanup, however, as it can cause undesired behaviour in some cases. In many cases it is safer to reject invalid entries.
• Use the appropriate libraries and frameworks for validation and cleanup in your programming language and framework. These often provide pre-built functionality and help to avoid common errors.
• Implement content type validation to ensure that requests match the expected data formats.

Rate Limiting and Throttling

Organisational measures

• Define clear rate limiting policies based on expected usage behavior, the capacity of your infrastructure, and the sensitivity of API endpoints. Consider different user groups and use cases.
• Communicate rate limits transparently to your API users through clear and understandable documentation. Specify the allowed request rates, the consequences of exceeding the limits, and any retry mechanisms.
• Regularly monitor and analyse API traffic patterns to assess the effectiveness of current rate limits and adjust them as necessary. Identify unusual behaviour or potential abuse.
• Consider the ability to define exceptions for trusted or premium users if it makes business sense.

Technical measures

• Select appropriate algorithms to implement rate limiting, such as Fixed Window, Sliding Window, Token Bucket or Leaky Bucket, based on your specific requirements for flexibility and accuracy.
• Implement rate limiting on the server side to ensure that controls cannot be bypassed by the client.
• Use API gateways or middleware components that provide built-in rate limiting and throttling capabilities. These often allow centralised management and configuration of rules.
• Use client identification mechanisms such as IP addresses, API keys or user accounts to track requests and enforce per-client throttling.
• Ensure that your implementation is scalable, especially in distributed systems where request counts may need to be synchronised.

Implementation notes

• Handle rate limit violations caused by HTTP status codes (e.g. 429 Too Many Requests) and add notes on retry strategies or limit reset time in response headers (e.g. X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset).
• Log rate limit events for monitoring and analysis to identify trends and optimise configuration.
• Thoroughly test your rate limiting and throttling mechanisms to ensure they work as expected and don't unnecessarily restrict legitimate users.
• Integrate API usage and rating limit effectiveness metrics into your monitoring systems to identify problems or potential abuse early.
• Consider differentiated rate limits for different API endpoints or user groups based on their sensitivity and expected usage.

Error Handling and Logging

Organisational measures

• Define clear error handling guidelines for your API. Determine which types of errors should be communicated to the client and how, and which should be logged internally.
• Train your developers on how to handle error situations and the importance of meaningful logging for API maintenance and security.
• Implement processes to periodically review log data to identify anomalies, potential security incidents, or recurring errors.
• Ensure that there are clear responsibilities for responding to logged security events and errors.

Technical measures

• Use standardised HTTP status codes to clearly communicate the type of error that has occurred (e.g. 400 for invalid request, 401 for unauthenticated, 500 for server error).
• Avoid revealing sensitive information in error messages, such as internal server paths, database details, or detailed stack traces. Instead, return generic error messages that help the user understand the problem without compromising security.
• Implement a centralised logging solution to store all relevant events in a secure location and facilitate analysis.
• Choose an appropriate logging format (e.g. JSON) that is both human-readable and suitable for automated analysis.
• Carefully configure the logging level to ensure a balance between detail and performance. Log enough information for troubleshooting and security analysis without draining resources unnecessarily.
• Implement monitoring tools that can provide real-time information about unusual API activity or error conditions (e.g. Grafana).

Implementation notes

• Log security-related events such as failed login attempts, authorisation errors, and suspicious API calls.
• Integrate contextual information into your logs, such as timestamp, client IP address, user ID, and the API route involved, to make it easier to trace events.
• Protect your log data from unauthorised access and tampering with appropriate access controls and encryption.
• Implement log rotation and archiving mechanisms to manage storage capacity and ensure retention periods are met.
• Ensure that your logging meets the requirements of relevant compliance regulations, such as HIPAA traceability of access to patient information.
• Thoroughly test your error handling and logging mechanisms to ensure that errors are handled correctly and that all relevant events are logged.

Regular Security Reviews and Improvements

Organisational measures

• Establish a fixed schedule for regular security audits, including vulnerability assessments, penetration tests and code reviews.
• Define clear responsibilities for performing and tracking security audits and implementing remediation actions.
• Integrate security considerations throughout the software development lifecycle (SDLC) to build security in from the start.
• Promote a culture of security within the development team through training on secure coding practices and the most common API vulnerabilities.
• Stay abreast of new threats and security recommendations by following resources such as the OWASP API Security Top 10 project.
• Implement security incident response policies, including the creation of dedicated incident response teams.

Technical measures

• Use automated vulnerability scanning tools to quickly identify known vulnerabilities in your API and its dependencies.
• Perform regular manual penetration tests to uncover complex vulnerabilities and logic flaws that may not be detected by automated tools.
• Implement static and dynamic code analysis tools to identify potential security issues in the source code at an early stage.
• Establish a comprehensive monitoring system to monitor API traffic, errors and suspicious activity in real time.
• Automate patch management to ensure that APIs and their dependencies are updated with the latest security updates in a timely manner.
• Use API gateways to monitor API traffic and centrally manage security policies.

Implementation notes

• Prioritise remediation of found vulnerabilities based on their severity and potential risk to your applications and data.
• Document all security checks performed, vulnerabilities found, and actions taken to remediate them.
• Thoroughly test any security enhancements you implement to ensure they have the intended effect and do not introduce new problems.
• Regularly review and update your security measures to keep pace with the evolving threat landscape.
• Incorporate lessons learned from security incidents into your regular security audits and improvements to learn from mistakes.
• Incorporate threat intelligence findings into your security strategy to proactively address potential future threats.

API Security Tools

Threat Prevention and Detection Tools

• These tools continuously monitor and analyse traffic.
• They automatically detect known threats in API traffic.
• They use behavioural and traffic analysis to detect deviations from normal API usage and identify anomalies.
• AI and machine learning can increase detection accuracy.
• This enables real-time response to attacks.
• Examples of tools in this category are:
• Wallarm API Security Platform provides automated threat detection.
• Salt Security uses behaviour-based API protection to detect anomalies.
• Reblaze provides protection against multiple attack methods.

Security Policy Enforcement Tools

• These tools manage user and application authentication.
• They control authorisation and restrict access to resources (e.g. using the principle of least privilege).
• They use encryption protocols such as TLS/SSL.
• They implement rate limiting and throttling.
• They validate incoming data to prevent injection attacks.
• They configure and manage CORS policies.
• They support compliance with regulatory compliance.
• API gateways centralise security policy management.
• Examples of tools in this category are:
• Reblaze can enforce security policies.
• API gateways such as Apigee, Kong Gateway or AWS API Gateway manage and enforce security policies.
• Wallarm API Security Platform and Salt Security can help enforce security policies by detecting and mitigating threats.

Security Assessment and Testing Tools

• These tools automatically scan APIs for security vulnerabilities.
• They validate input and output.
• They check for excessive data exposure.
• They identify vulnerabilities such as Broken Object Level Authorization, Broken User Authentication or configuration errors.
• They simulate attacks as part of penetration testing.
• They test the rate limit.
• They enable regular safety assessments.
• Integration with CI/CD pipelines is possible.
• They provide reports and analysis of test results.
• They assess compliance with security standards.
• Examples of tools in this category are:
• OWASP ZAP is used to scan APIs for vulnerabilities.
• StackHawk is suitable for integrating security testing into the development process.
• Beagle Security provides an easy-to-use interface for API security testing.
• Postman Security Scanner can be used to test APIs and their security mechanisms.

Further information and links

Information

• OWASP API Security Top 10
  https://owasp.org/API-Security/editions/2023/en/0x00-header/
• IBM: "Cost of a Data Breach Report 2024"
  https://www.ibm.com/reports/data-breach