Web application programming interfaces (APIs) provide the back end for modern web and mobile applications. Web API calls account for over 80% of all web traffic and cybercriminals are increasingly targeting APIs, so ensuring web API security is crucial. REST APIs are the most common type of web API for web services. Let’s see what you can do to ensure REST API security.
What Is a REST API?
REST (short for REpresentational State Transfer) is a software architecture style for web development, usually used with HTTP communication. RESTful APIs (or simply REST APIs) are application programming interfaces that follow REST principles, allowing web clients and servers to interact with a huge variety of web resources. REST APIs use standard HTTP verbs (methods) and status codes to provide some level of standardization. They are accessed via HTTP URLs and are widely used for web services.
Note: REST APIs are stateless like the HTTP protocol itself, meaning that they don’t store any information about current connections or sessions. RESTful web services provide ways to access and manipulate resources, while session management should be handled by the application.
Two Levels of REST API Security
Before we get into the technical details, there is one important thing to note. A web API exposes an interface to a web application, so you need to think about security on two levels: access to the API and then access to the application.
On the API level, you need the proper authentication, authorization, access privileges, and so on, to ensure that only permitted clients can use the interface and only execute permitted operations. On the application level, you need to ensure that your application endpoints (the URLs used to access the interface) are not vulnerable to attacks that get through the interface or bypass it.
Let’s see how you can ensure REST API security on these two levels. For a detailed discussion of API security best practices, see the OWASP REST Security Cheat Sheet.
Ensuring Secure API Access
Most web APIs are exposed to the Internet, so they need suitable security mechanisms to prevent abuse, protect sensitive data, and ensure that only authenticated and authorized users can access them.
Security starts with the HTTP connection itself. Secure REST APIs should only provide HTTPS endpoints to ensure that all API communication is encrypted using SSL/TLS. This allows clients to authenticate the service and protects the API credentials and transmitted data.
API Access Control
Many web APIs are available only to authenticated users, for example because they are private or require registration or payment. Because REST APIs are stateless, access control is handled by local endpoints. The most common REST API authentication methods are:
- HTTP Basic Authentication: Credentials are sent directly in HTTP headers in Base64 encoding without encryption. This is the simplest authentication method and the easiest to implement. It also the least secure, since confidential data is transmitted as plain text, so it should only be used in combination with HTTPS.
- JSON Web Tokens (JWT): Credentials and other access parameters are sent as JSON data structures. These access tokens can be signed cryptographically and are the preferred way of controlling access to REST APIs. See the OWASP JWT Cheat Sheet for a quick overview of JSON Web Tokens, and RFC 7519 for the full specification.
- OAuth: Standard OAuth 2.0 mechanisms can be used for authentication and authorization. OpenID Connect allows secure authentication over OAuth 2.0. For example, Google’s APIs use OAuth 2.0 for authentication and authorization.
User Authorization with API Keys
API keys provide a way of controlling access to public REST services. Operators of public web services can use API keys to enforce rate limiting for API calls and mitigate denial-of-service attacks. For monetized services, organizations can use API keys to provide access based on the purchased access plan.
API Client Restrictions
To minimize security risks, REST service operators should restrict connecting clients to the minimum capabilities required for the service. This starts with restricting supported HTTP methods to make sure that misconfigured or malicious clients can’t perform any actions beyond the API specification and permitted access level. For example, if the API only allows GET requests, POST and other request types should be rejected with the response code 405 Method not allowed.
Protecting Applications that Expose APIs
Once the client has legitimate access, you need to protect the underlying web application from malformed and malicious inputs. REST API calls and responses may also include confidential data that needs to be controlled.
Sensitive Data in API Communication
API calls often include credentials, API keys, session tokens, and other sensitive information. If included directly in URLs, these details could be stored in web server logs and leaked if the logs are accessed by cybercriminals. To avoid leaking confidential information, RESTful web services should always send it in HTTP request headers or the request body (for POST and PUT requests).
Content Type Validation
Continuing the theme of API client restrictions, REST services should precisely define permitted content types and reject requests that don’t have the correct declarations in their HTTP headers. This means carefully specifying permitted types in both the
Content-Type and the
Response Security Headers
Additional HTTP security headers can be set to further restrict the type and scope of requests. These include
X-Content-Type-Options: nosniff to prevent XSS attacks based on MIME sniffing and
X-Frame-Options: deny to prevent clickjacking attempts in older browsers.
If the service doesn’t support cross-domain calls, it should disable CORS (cross-origin resource sharing) in its response headers. If such calls are expected, the CORS headers should precisely specify the permitted origins.
APIs are designed for automated access without user interaction, so it is especially important to ensure that all inputs are valid and expected. Any requests that don’t conform to the API specification must be rejected. Typical best-practice guidelines for input validation apply:
- Treat all parameters, objects, and other input data as untrusted.
- Use built-in validation functionality where available.
- Check the request size and content length and type.
- Use strong typing for API parameters (if supported).
- To prevent SQL injection, avoid building queries manually – use parameterized queries instead.
- Whitelist parameter values and string inputs wherever possible.
- Log all input validation failures to detect credential stuffing attempts.
Why REST API Security Is Important
Web APIs are the backbone of modern web and mobile development. They allow applications and services to communicate and exchange data across hardware and software platforms. While other API formats are also still in use (for example SOAP), REST APIs are now the dominant type, accounting for over 80% of all public web APIs. They provide the back end for the majority of mobile applications and IoT devices and allow easy integration across systems and applications.
Because they use the same technologies as web applications, REST APIs can be vulnerable to the same attacks. At the same time, APIs are not designed for manual access, so they can be difficult to test, especially if some endpoints and features are undocumented. API security testing requires accurate automated tools to ensure complete coverage. Netsparker provides full support for REST API vulnerability scanning with a variety of authentication methods and automatic URL rewriting.
See the Netsparker REST API test site documentation for complete technical details and read our full article on scanning REST APIs for vulnerabilities with Netsparker.