REST API Security Best Practices
What is a REST API?
A REST API is an API that conforms to specific architectural constraints associated with web-based applications, including stateless communication and cacheable data. REST APIs allow browser apps, mobile apps, and other API clients to communicate with a server. What follows are the top 10 REST API security guidelines based on customer experiences and issues highlighted in the most recent State of API Security report from Salt Security. As time and resources permit, consider adopting the full set of API security best practices described in the Salt API Security Best Practices guide. You can also make use of the corresponding API security checklist to track associated work.
Unlike some other API types, REST is a style as opposed to a strict standard. REST APIs can be designed in numerous ways, which impacts how functionality is invoked or how data is passed in a request. Resulting REST API schema and endpoint URL structure can vary greatly from one organization to the next. REST APIs are implemented, operated, or interacted with by many roles within an organization including development, product teams, operations teams, application security teams, and security operations. REST APIs are one of the most common kinds of web services in use today. It’s imperative to design REST APIs properly, taking into account security, performance, and ease of use for REST API consumers.
Top 10 REST API Security Guidelines
1. When generating REST API documentation, opt for machine formats and schema definitions as opposed to traditional documentation or visual diagrams.
Most commonly for REST APIs, these machine formats include Swagger or OAS. Depending on your REST API design, development or publishing tooling, other formats like RAML or REST API Blueprint may be present. Traditional documentation can be useful for reviews by a less technical audience, but such forms of documentation are not easily maintained. The REST API schema definition formats are designed for quick generation of documentation as part of REST API design and mocking that is also reusable for testing, integration, publishing, and operations.
2. Discover REST APIs in non-production environments, not just production environments.
It’s critically important that you track lower environments including QA, UAT, staging, SIT, and pre-production in addition to your production environments. Attackers know that non-production environments often have fewer relaxed or no security controls, yet REST APIs in those environments may still allow access to similar sets of functionality and data. Organizations often set up lower environments with minimal hardening to help promote rapid development and integration to meet production goals and release schedules. Lower environments may also be Internet exposed which further elevates the security risk.
3. Include the dependencies of your REST APIs.
Expand beyond just homegrown REST APIs to also include REST APIs from open-source software, acquired application packages, and third-party SaaS services. REST API security concerns don’t begin and end with just your custom-built REST APIs. Vendor risk attestation and contractual language are useful primarily as reactive measures that provide for legal recourse, and they provide minimal guarantee at the technology layer. Organizations are inherently limited by the configuration options that are within their realm of control for third-party services. This limitation does not absolve the organization from security risk though. Significant gaps often exist between perceived design of an application and its REST APIs as opposed to the delivered, integrated system. The combination of built, integrated, and acquired APIs defines the digital supply chain that all organizations work within. Similarly, you must also account for other API types, such as gRPC, GraphQL and SOAP.
4. Analyze REST API code automatically where possible.
Analyze code automatically with static analysis tools like code quality checkers and static application security testing (SAST) upon code commit in version control systems such as git and/or in CI/CD build pipelines. If you are reviewing code manually, the process will quickly hit a wall with the rate of change most organizations see in their code and REST APIs. Scan the integrated code base as part of build within CI/CD to obtain the most accurate scan, but some organizations also opt to scan pieces of code as they are committed to version control for speediness. A code quality checker is the least purpose-built, but they are often plentiful in organizations since many design and development tools include native code quality checking capabilities. SAST may be delivered through language-specific linters or a commercial-grade scanning offering. Regardless of the tool you select, brace for high numbers of findings of potential weaknesses and false positives, particularly if a codebase has never been scanned. Static analyzers notoriously need tuning to be used effectively. Static analysis will not be able to cover business logic flaws by design, which requires runtime behavior analysis.
5. Mediate REST APIs to enforce access control.
API gateways are often deployed to provide visibility and control over REST API calls for data exchange or functionality. API gateways are foundational mediation mechanisms that provide traffic management, authentication, and authorization. Traffic management functions map to well-known network security controls such as rate limits or IP address allow and deny lists. API gateways are also an ideal place to enforce authentication and authorization for REST APIs, such as OpenID Connect (OIDC) and OAuth2 respectively. Typically, API gateways are paired with external identity and access management (IAM) systems to share the load of storing all types of user or machine identities, authenticating identities, authorizing identities, and maintaining audit trails of all activity. Machine consumption of your REST APIs (such as in automation use cases or partner integration) can be just as dominant as traditional end user consumption through browser-based apps and mobile apps.
Get the comprehensive list of best practices to guide your API security journey.
Download Now6. Use encrypted transport to protect the data your REST APIs transmit.
TLS should be enabled for any REST API endpoints to protect data in transit. Aim for TLS 1.2 at a minimum, and ideally enable TLS 1.3 if other architectural elements support it. All versions of SSL should be disabled due to the number of weaknesses in the protocol or related cipher suites. Legacy infrastructure components sometimes linger within organizations or suppliers, requiring that SSL or older versions of TLS be maintained. Some traffic inspection tooling may also not support more recent encryption protocols, which puts organizations in a bind when they want to maintain visibility over their network traffic. Unfortunately, supporting older protocols and cipher suites exposes the organization to a number of cryptographic and downgrade attacks that can result in encrypted data being viewable by unauthorized parties. Enforce encryption policies through your REST API mediation layers wherever possible, and ensure legacy protocols and cipher suites are kept disabled. If necessary, refactor or re-architect the supporting infrastructure of your REST APIs, opting for TLS termination points that allow you to maintain traffic visibility while still mitigating security risk of encryption protocol attacks.
7. Avoid sending too much data to REST API clients.
REST API clients or front-end code commonly takes the form of JavaScript running within a web browser or mobile application binaries on a mobile device. Back-end REST APIs are sometimes designed to serve up a great deal of data in responses to REST API calls from API clients, and it becomes the duty of the front-end client code to filter out what should be visible based on the goals of the user experience (UX) or permission levels. This design pattern goes against REST API security best practice since that data is fully visible by observing REST API requests and responses. Attackers commonly reverse engineer front-end code and sniff REST API traffic directly to see what data is actually being transmitted. The issue ranks as one of the OWASP REST API Security Top 10 as API3:2019 Excessive Data Exposure because it is so commonplace. Don’t send too much data, particularly sensitive or private data, to front-end clients and always presume that they are compromised. Filter data appropriately in the back end and send only the data that is necessary for that particular REST API consumer.
8. Authenticate and continuously authorize REST API consumers.
Access control has always involved authentication and authorization. Authentication (AuthN), involves identifying the requester of a given function or resource and challenging that entity for authentication material or credentials. Authorization (AuthZ) involves verifying whether that authenticated entity actually has permissions to exercise a function or read, write, update, or delete data. Traditionally, both were handled at the start of a session. In the web world, and by extension REST APIs, sessions are stateless. The operating environments of back-ends and front-ends are not guaranteed and often ephemeral. Increasingly, environments are also prone to integrity issues or compromise, hence the rise of zero trust architectures. As a result, you must continuously verify whether a user or machine identity should have access to a given resource and always presume the authenticated session might be compromised. This approach requires analyzing behaviors of a given session for a REST API consumer, and potentially terminating that session, requiring step-up authentication, or blocking access as appropriate.
9. Explore behavior analysis and anomaly detection.
As organizations adopt REST APIs, they quickly realize the need for machine-driven data analytics and behavior analysis to understand normal REST API consumption and identify attackers abusing REST APIs. The algorithms must be informed by REST API metadata as well as REST API traffic collection, continuously learn, and make decisions dynamically based on the organization’s unique business logic. Machine-driven detection and protection should also be built into a larger platform of services and integration so that an appropriate mitigating action, such as setting a dynamic rate limit for an abusive requester, can be implemented temporarily at the appropriate network ingress of the overall architecture. Even mature organizations with development and data science resources quickly hit a wall trying to develop such detection and integration. You will inevitably need to explore REST API security tooling to fill this gap.
10. Create API-centric incident response playbooks for REST APIs.
Ensure that you document digital forensics and incident response (DFIR) processes for how to respond to the inevitable REST API attack patterns. If you’ve already matured your SecOps strategy to include the use of security orchestration, automation and response (SOAR), then also automate some of the workflow items as part of IR. Shutting down a REST API that is the target of malicious activity is rarely a prudent business decision, not to mention it reduces your ability to gain additional intelligence about an attacker and their techniques. Rather than blocking traffic wholesale, you will likely want to employ more precision such as throttling just the suspicious REST API caller, challenging them with additional authenticator factors, or monitoring their behavior more heavily. Create IR playbooks for common REST API attack patterns including application-layer DoS, brute forcing, credential stuffing, enumeration, and scraping.
REST API Security Best Practices Summary
This set of API security best practices is tailored specifically to REST API types and the most common sets of security problems that organizations face. Start by picking a few best practices areas as a starting point that are most familiar. Expand your API security strategy over time to cover all the best practices and avoid gaps in your organization’s API security posture. Consider adopting the full set of API security best practices described in the Salt API Security Best Practices guide as part of a comprehensive approach to cover all types of APIs. You can also make use of the corresponding checklist to track associated work.
If you’re interested in seeing the Salt Security API Protection Platform in action, contact us for a customized demo today!
