rvlsoft - Fotolia
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
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.
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.
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.