How to secure REST API endpoints for cloud applications
When designing APIs, developers must make good decisions about security design components that show who's using what API, when and for what purpose. This tip offers insights into the critical components for securing APIs.
Because security is a business requirement for any application deployed in the public cloud, API architects must make security a top priority when designing public APIs for others to use in client applications. Currently, most public APIs are based on representational state transfer (REST) with Javascript object notation (JSON) or Extensible Markup Language (XML). The flexibility and open nature of REST, JSON and XML make secure design considerations essential to protect the service endpoints and data from threats.
When designing APIs, developers must make good decisions about security design components, such as authentication, authorization, monitoring and tracking, all functions that show which user is using what API, when and for what purpose.
REST APIs, available over HTTP or HTTPS protocols, use JSON or XML for data formatting. REST performs these basic actions: GET (read or list), POST (create), PUT (update) and DELETE (delete).
When a developer or architect designs a REST API, it's imperative that the API be designed so that only authenticated and authorized users can perform actions. In design, the first step to securing an API endpoint is to determine which exposed actions need to be secured. Secure design requires that architects consider authentication, authorization and protecting the session state. Adding security to an API design enables development resources to own and assist in controlling the API, along with IT or DevOps resources. Also, it allows IT and DevOps resources to focus on higher-level security concerns rather than tracking each public API the organization publishes.
Authentication and API keys
When a developer or architect designs a REST API, it's imperative that the API be designed so that only authenticated and authorized users can perform actions.
Hash-based message authentication code (HMAC) is an option that provides the server and the client each with a public and private key. The public key is known, but the private key is known only to that server and that client. The client creates a unique HMAC, or hash, per request to the server by combing the request data and hashing that data, along with a private key and sending it as part of a request. The server receives the request and regenerates its own unique HMAC. The server compares the two HMACs, and, if they're equal, the client is trusted and the request is executed. This process is often called a secret handshake.
Another option is using open authorization (OAuth) within an API, along with a JSON Web token (JWT). Typically, OAuth specifies four roles: resource owner, client, resource server and authorization server. Each client using an API receives a unique API key embedded within a JWT for authentication.
Both options provide security on the API for authentication, and both options are complex to set up. The preference of the developer, architect or DevOps determines which option an organization chooses.
Authorization of public APIs
Authorization is achievable via several methods, but protecting the HTTP methods and whitelisting are preferred and available for monitoring with security intelligence systems.
Protecting HTTP methods with a REST API means setting user privileges on the GET, POST, PUT and DELETE actions of REST. Not every API user needs access to each of these actions. Setting up authorization based on privilege level means that only the users authorized to use DELETE can actually remove data records. At a minimum, most users should have access to records or a list of information. Based on the API client terms or the organization's terms of use, some users may be allowed to create or update data records.
Authorization via privileged HTTP method access isn't applicable only to users; it may be applied to resource collections. Setting authorization based on privilege or a user's role is a relatively common, but effective layer to include in API endpoint security.
Whitelisting methods are another option. Whitelisting allows authorization based on a URL. The methods remain GET, POST, PUT and DELETE, but use of the methods is restricted based on the URL's presence in a whitelist, with an assigned set of actions allowed. If a URL is not in the list, then an error response code, such as 403 – Forbidden, is returned. It's advisable when using this method to ensure server and system information is removed from the standard error message so no internal system information is presented.
An advantage of using method whitelisting is it can be monitored via access logs and data tracked in logs or by security intelligence systems.
Protecting session states
Most Web services and APIs are designed to be stateless, with a state blob being sent within a transaction. For a more secure design, consider using the API key to maintain client state if the API is using a server-side cache. It's a commonly used method in Web applications and provides additional security by preventing anti-replay. Anti-replay is where attackers cut and paste a blob to become an authorized user. In order to be effective, include a time-limited encryption key that is measured against the API key, date and time, and incoming IP address.
The key to effective security is layering combined with active monitoring. Layering provides one or more backup systems in case one is compromised. Data and access are still protected by the next layer. Monitoring activity with an API allows an organization to retain control of the API and ensure it's used in a manner consistent with its contract or terms of use and not as an access point into an organization's or API user's system.
An API architect must design API endpoint security from the beginning for the public API to provide the greatest value to an organization and its users, and deliver ownership of security within the development team. Even if an API is not used to connect to, or transfer confidential or common forms of protected data, API endpoints are access points and have been used as engines for hackers to gain unauthorized access to networks and data. Endpoint security provides protection for a business and its customers.
