Web APIs are the lifeblood of web development, providing the back-end and internal communications for the vast majority of 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 – and REST APIs are by far the most common type of web API for web services and microservices. This post shows how to test your web application interfaces for vulnerabilities and ensure REST API security.
What is a REST API?
REST (short for Representational State Transfer) is a software architecture style for web development, most often 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 are accessed via HTTP URLs and are the most popular way to communicate with web services.
By convention, REST APIs use standard HTTP verbs (methods) and status codes, with JSON being the usual data format, but REST itself is not a strict standard or format. Other, more standardized web API formats do exist, two popular technologies being SOAP (which is XML-based) and GraphQL (which allows database-like API queries).
Also note that 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. This is where many API security issues arise, as insecure application code may lead to vulnerabilities that enable API-based attacks.
Two levels of REST API security
One important thing to note before we get into the technical details. A web API provides a way to access a web application, so you need to think about security on two levels: access to the API and then access to the application. Security on the API level means that you need the proper authentication, authorization, and access privileges 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 (i.e. the URIs 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.
Connection security
Security starts with the HTTP connection itself. Secure REST APIs should only expose HTTPS endpoints, which will 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 from man-in-the-middle attacks and other traffic sniffing.
API access control
Most web APIs are available only to authenticated users, often because they are private or require registration or payment. Because REST APIs are stateless, all access control and auth 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 user authentication method is the simplest and the easiest to implement. However, it is also the least secure because it sends sensitive information in plain text, so it should only ever be used in combination with HTTPS to ensure that traffic containing these requests is encrypted.
- 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 our blog posts for more information about JWT security in general and JSON Web Token vulnerabilities in particular.
- 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 based on 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 a level of access corresponding to a specific access plan purchased by the user.
API client restrictions
To minimize security risks, REST service operators should restrict API requests to the bare minimum set of 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 all other request types should be rejected with the response code 405 Method not allowed.
Protecting applications that expose APIs
Once a web API client has obtained 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 a suitable level of protection.
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 obtained by cybercriminals. To avoid leaking confidential information, RESTful web services should always send it in HTTP request headers or in the request body (for POST and PUT requests).
Content type validation
As part of imposing API client restrictions, REST services should precisely define permitted content types and reject all requests that don’t have the correct declarations in their HTTP headers. This means carefully specifying permitted types in the Content-Type and Accept headers, along with the charset (where possible). If the service includes JavaScript or other script code, you need to set the same content type in the header and the request body, for example application/javascript. This helps to prevent header injection attacks. Similarly, if your endpoint never returns HTML, setting the correct content type reduces the risk of the response being parsed as HTML.
Security headers in responses
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 cross-site scripting (XSS) attacks based on MIME sniffing and X-Frame-Options: deny to prevent clickjacking attempts in older browsers.
If your service doesn’t support cross-domain calls, you should disable CORS (Cross-Origin Resource Sharing) in its response headers. If such calls are expected behavior, you should set CORS headers that precisely specify the permitted origins.
Input validation
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. Here are some general guidelines for REST API input validation:
- Use built-in validation and encoding functionality where available.
- Treat all parameters, objects, and other input data as untrusted by default.
- Always check the request size, content length, and content 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 (rather than blacklisting).
- Log and monitor all input validation failures to detect credential stuffing attempts.
Why REST API security is so 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 SOAP APIs still have their uses and GraphQL is on the rise in big data applications, REST APIs are by far 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. Alongside its industry-leading web application security testing features, Invicti also allows REST API vulnerability scanning out-of-the-box, with support for all popular authentication methods (including OAuth2) and automatic URL rewriting.
At Invicti, we believe that application security testing should include web APIs as a matter of course, not as an optional extra. Get our white paper on web API security to learn more, see the Invicti REST API test site documentation for technical details of REST API testing, and read our full article on scanning REST APIs for vulnerabilities with Invicti.
