Navigating the API Security Landscape: A Guide to Building Secure Microservices

Microservices have become a popular architecture for building and deploying modern applications. By breaking down a monolithic application into smaller, independently deployable services, teams are able to move faster, iterate more quickly, and scale more easily.

However, as with any distributed system, microservices (as shown in Figure 1) come with their own set of security challenges. In this post, we will explore the history of microservices, the benefits they offer, and some of the key challenges related to API security.

A Brief History of Microservices

The term “microservices” was first coined by Martin Fowler and James Lewis in 2014, but the concept has been around for much longer. In the early days of software development, applications were often built as monolithic blocks of code (as shown in Figure 2) that were difficult to maintain and update. As the field of software engineering evolved, developers began to explore more modular approaches to building applications.

One such approach was the “service-oriented architecture” (SOA), which involved breaking down a monolithic application into a set of smaller, independently deployable services. Each service was responsible for a specific function and could be updated and deployed independently of the rest of the application.

The microservices architecture takes this concept a step further by breaking down each service into even smaller, more focused units of functionality. This allows teams to move faster, iterate more quickly, and scale more easily.

Benefits of Microservices

There are several benefits to using a microservices architecture:

• Faster development: By breaking down a large application into smaller, independent services, teams are able to work on individual components in parallel. This can significantly speed up development and deployment cycles.
• Easier to scale: Because each microservice is a self-contained unit of functionality, it is easier to scale individual services as needed. This can help reduce the complexity of scaling a large, monolithic application.
• Improved fault isolation: In a microservices architecture, if one service goes down, it does not necessarily bring down the entire application. This can help improve the overall stability and reliability of the system.
• Easier to maintain: Because each microservice is a standalone unit of functionality, it is easier to maintain and update individual components without affecting the rest of the application.

API Security Challenges in Microservices

API security is a critical concern in microservices architectures (as shown in Figure 3), as without proper security measures, sensitive data could be exposed, and unauthorized actions could be performed. The OWASP Top 10 is a list of the most common and critical security risks facing web applications and APIs, and the latest version, OWASP Top 10 – API Security, focuses specifically on the security risks facing APIs. In this section, we will delve deeper into some of the key API security challenges in microservices and explore how the OWASP Top 10 – API Security can be applied to microservices architectures.

A1:2019 – Broken Object Level Authorization

This risk involves APIs that do not properly enforce object-level authorization, allowing unauthorized users to access or modify sensitive data. In a microservices architecture, this risk can occur when APIs do not properly authenticate and authorize requests, or when access controls are not implemented correctly.

To prevent this risk, organizations should ensure that APIs are properly configured to enforce object-level authorization and that access controls are implemented correctly.

• To prevent Broken Object Level Authorization in microservices architectures, it is important to implement a proper authorization mechanism that is based on user policies and hierarchy.
• This mechanism should be used to verify that the logged-in user has permission to perform the requested action on the record for every function that accesses a record in the database using input from the client.
• To further secure records, it is recommended to use random and unpredictable values, such as GUIDs, as IDs for records.
• To ensure the effectiveness of the authorization mechanism, it is also important to write tests and avoid deploying any changes that may compromise the security of the system.

A2:2019 – Broken Authentication

This risk involves APIs that do not properly authenticate users or devices, allowing unauthorized access to sensitive data. In a microservices architecture, this risk can occur when APIs do not properly validate user credentials or when API keys and tokens are not secured.

To prevent this risk, organizations should ensure that APIs are properly configured to authenticate users and devices and that API keys and tokens are securely managed.

• Make sure you know all the possible flows to authenticate to the API (mobile/ web/deep links that implement one-click authentication/etc.)
• Ask your engineers what flows you missed.
• Read about your authentication mechanisms. Make sure you understand what and how they are used. OAuth is not authentication, and neither is API keys.
• Don’t reinvent the wheel in authentication, token generation, password storage. Use the standards.
• Credential recovery/forget password endpoints should be treated as login endpoints in terms of brute force, rate limiting, and lockout protections.
• Use the OWASP Authentication Cheatsheet.
• Where possible, implement multi-factor authentication.
• Implement anti brute force mechanisms to mitigate credential stuffing, dictionary attack, and brute force attacks on your authentication endpoints. This mechanism should be stricter than the regular rate limiting mechanism on your API.
• Implement account lockout / captcha mechanism to prevent brute force against specific users. Implement weak-password checks.
• API keys should not be used for user authentication, but for client app/ project authentication.

A3:2019 – Excessive Data Exposure

This risk involves APIs that expose sensitive data to unauthorized parties. In a microservices architecture, this risk can occur when APIs are not properly configured to limit access to sensitive data or when data is not properly encrypted in transit or at rest.

To prevent this risk, organizations should ensure that APIs are properly configured to limit access to sensitive data and that data is encrypted in transit and at rest.

• Never rely on the client side to filter sensitive data.
• Review the responses from the API to make sure they contain only legitimate data.
• Backend engineers should always ask themselves “who is the consumer of the data?” before exposing a new API endpoint.
• Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick specific properties you really want to return
• Classify sensitive and personally identifiable information (PII) that your application stores and works with, reviewing all API calls returning such information to see if these responses pose a security issue.
• Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism define and enforce data returned by all API methods, including errors.

A4:2019 – Lack of Resources & Rate Limiting

This risk involves APIs that do not properly limit the number of requests that can be made, allowing attackers to flood the API with traffic and potentially bring it down. In a microservices architecture, this risk can occur when APIs do not implement rate limiting or when there are not enough resources to handle the traffic.

To prevent this risk, organizations should ensure that APIs are properly configured to limit the number of requests that can be made and that there are sufficient resources to handle the traffic.

• Docker makes it easy to limit memory, CPU, number of restarts, file descriptors, and processes.
• Implement a limit on how often a client can call the API within a defined timeframe.
• Notify the client when the limit is exceeded by providing the limit number and the time at which the limit will be reset.
• Add proper server-side validation for query string and request body parameters, specifically the one that controls the number of records to be returned in the response.
• Define and enforce maximum size of data on all incoming parameters and payloads such as maximum length for strings and maximum number of elements in arrays.

A5:2019 – Broken Function Level Authorization

This risk involves APIs that do not properly enforce function-level authorization, allowing unauthorized users to perform unauthorized actions. In a microservices architecture, this risk can occur when APIs do not properly authenticate and authorize requests or when access controls are not implemented correctly.

To prevent this risk, organizations should ensure that APIs are properly configured to enforce function-level authorization and that access controls are implemented correctly.

• The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
• Review your API endpoints against function level authorization flaws, while keeping in mind the business logic of the application and groups hierarchy.
• Make sure that all of your administrative controllers inherit from an administrative abstract controller that implements authorization checks based on the user’s group/role.
• Make sure that administrative functions inside a regular controller implements authorization checks based on the user’s group and role.

A6:2019 – Mass Assignment

This risk involves APIs that allow users to modify sensitive data without proper authorization. In a microservices architecture, this risk can occur when APIs do not properly validate user input or when access controls are not implemented correctly.

To prevent this risk, organizations should ensure that APIs properly validate user input and enforce access controls.

• If possible, avoid using functions that automatically bind a client’s input into code variables or internal objects.
• Whitelist only the properties that should be updated by the client.
• Use built-in features to blacklist properties that should not be accessed by clients.
• If applicable, explicitly define and enforce schemas for the input data payloads.

A7:2019 – Security Misconfiguration

This risk involves APIs that are not properly configured, leading to vulnerabilities that can be exploited by attackers. In a microservices architecture, this risk can occur when APIs are not properly secured or when security configurations are not properly managed.

To prevent this risk, organizations should ensure that APIs are properly secured and that security configurations are properly managed.

The API life cycle should include:

• A repeatable hardening process leading to fast and easy deployment of a properly locked down environment.
• A task to review and update configurations across the entire API stack. The review should include: orchestration files, API components, and cloud services (e.g., S3 bucket permissions).
• A secure communication channel for all API interactions access to static assets (e.g., images).
• An automated process to continuously assess the effectiveness of the configuration and settings in all environments.

Furthermore:

• To prevent exception traces and other valuable information from being sent back to attackers, if applicable, define and enforce all API response payload schemas including error responses.
• Ensure API can only be accessed by the specified HTTP verbs. All other HTTP verbs should be disabled (e.g., HEAD).
• APIs expecting to be accessed from browser-based clients (e.g., WebApp front-end) should implement a proper Cross-Origin Resource Sharing (CORS) policy.

A8:2019 – Injection

This risk involves APIs that are vulnerable to injection attacks, in which malicious code is injected into the API in an attempt to gain access to sensitive data or perform unauthorized actions. In a microservices architecture, this risk can occur when APIs do not properly validate user input or when APIs are not properly secured.

To prevent this risk, organizations should ensure that APIs properly validate user input and are properly secured.

• Perform data validation using a single, trustworthy, and actively maintained library.
• Validate, filter, and sanitize all client-provided data, or other data coming from integrated systems.
• Special characters should be escaped using the specific syntax for the target interpreter.
• Prefer a safe API that provides a parameterized interface.
• Always limit the number of returned records to prevent mass disclosure in case of injection.
• Validate incoming data using sufficient filters to only allow valid values for each input parameter.
• Define data types and strict patterns for all string parameters.

A9:2019 – Improper Asset Management

This risk involves APIs that do not properly manage assets, such as keys and tokens, leading to vulnerabilities that can be exploited by attackers. In a microservices architecture, this risk can occur when assets are not properly secured or when they are not properly managed.

To prevent this risk, organizations should ensure that assets are properly secured and properly managed.

• Inventory all API hosts and document important aspects of each one of them, focusing on the API environment (e.g., production, staging, test, development), who should have network access to the host (e.g., public, internal, partners) and the API version.
• Inventory integrated services and document important aspects such as their role in the system, what data is exchanged (data flow), and its sensitivity.
• Document all aspects of your API such as authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy and endpoints, including their parameters, requests, and responses.
• Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline.
• Make API documentation available to those authorized to use the API.
• Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version.
• Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones.
• When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatibility or you need to take the older version out quickly and force all clients to move to the latest version.

A10:2019 – Insufficient Logging & Monitoring

This risk involves APIs that do not properly log and monitor activity, making it difficult to detect and respond to security threats. In a microservices architecture, this risk can occur when APIs are not properly configured to log and monitor activity or when there are not sufficient resources for logging and monitoring.

To prevent this risk, organizations should ensure that APIs are properly configured to log and monitor activity and that there are sufficient resources for logging and monitoring.

• Log all failed authentication attempts, denied access, and input validation errors.
• Logs should be written using a format suited to be consumed by a log management solution and should include enough detail to identify the malicious actor.
• Logs should be handled as sensitive data, and their integrity should be guaranteed at rest and transit.
• Configure a monitoring system to continuously monitor the infrastructure, network, and the API functioning.
• Use a Security Information and Event Management (SIEM) system to aggregate and manage logs from all components of the API stack and hosts.
• Configure custom dashboards and alerts, enabling suspicious activities to be detected and responded to earlier.

By understanding the OWASP Top 10 – API Security risks and implementing appropriate safeguards, organizations can secure their APIs in a microservices architecture and protect against the most common and critical security threats.

Conclusion

In conclusion, API security is an essential consideration in microservices architectures. With APIs serving as the backbone of communication between different microservices, securing these APIs is crucial to protecting sensitive data and preventing unauthorized actions. By understanding the key API security challenges in microservices and implementing appropriate safeguards, such as protecting API keys and tokens, reducing the risk of API vulnerabilities, and preventing denial of service attacks, organizations can build and deploy powerful applications with confidence. Additionally, by following the OWASP Top 10 – API Security guidelines and best practices, organizations can protect against the most common and critical security threats facing APIs. By investing in API security, organizations can unlock the full potential of microservices and build reliable, secure applications that meet the needs of their users and customers.