API Security Best Practices

Protecting Your Innovation Capabilities

In today’s application-driven world, Application Programming Interfaces (APIs) drive innovation and digital transformation by connecting applications and enabling them to exchange data. Across all industries, APIs play a vital role in the functions of mobile, SaaS, and web applications that customers, partners, and internal users rely on to conduct business.

One of the key aspects to focus on when developing APIs is security. APIs expose application logic and sensitive data, thus making them a prime target for cyberattacks. Without secure APIs, the innovation that drives customer purchases and increases workforce efficiency would be impossible. And due to the particular nature of APIs, a specific security strategy is required that focuses on mitigating the unique vulnerabilities and security risks associated with APIs.

These include misconfigurations of security controls and improper asset management as well as insufficient logging and monitoring. Other common API security issues include broken object-level authorization, function-level authorization, and user authentication. APIs can also be put at risk by excessive data exposure and the lack of rate-limiting, which drains compute resources.

This article examines best practices you can apply to protect your Web APIs and your REST APIs to help you take on the challenges of API security. We also discuss how an API gateway can add an extra layer of security.

Free!

A Business Leader’s Guide to APIs

Download Now!

Security Best Practices for Web APIs

Web APIs provide interfaces among web servers and web browsers and are among the most commonly-used API types. Here’s a rundown of three security measures you can utilize to protect your Web APIs:

• Apply cryptography to control access. You can do this with hash message authentication code (HMAC) signatures. Secret cryptographic keys within the signature verify data integrity and the authenticity of messages. When a client device calls the API, the hashed message generates a signature. The server receiving the API call then retrieves a signature from the secret key stored on the server. If both signatures match, the request is authorized.
• Restrict access to API endpoints. In cases where you want to limit access to API endpoints, the OAuth 2 protocol comes in handy. Clients must first log into a single open endpoint and provide their API credentials. The server then authenticates and provides a token to the client, which permits access to restricted endpoints and the services offered by the API.
• Verify the authenticity of API calls. Digital signature exchanges help protect private keys used by clients and API servers while also making it possible to verify the authenticity of API calls. When a client initially calls the API server, the public key within the signature can be checked against the corresponding private key on the API server to verify the call’s authenticity. Subsequent requests from the client to the server can then be signed with the client’s private key. In this arrangement, the private keys on both the client and the server remain protected from each other.

Another inherent attribute that helps secure your Web APIs is that they are stateless. This forces the clients that are calling an API service to pass the message context to the API server and provide credentials that the server can then validate before processing client requests.

Security Best Practices for REST APIs

Another common API is the Representational State Transfer (REST) API, which provides interoperability between online computer systems and, just like the Web API, is inherently stateless. There are multiple ways to secure these REST APIs:

• Protect passwords. Use a hashing algorithm to generate password hashes that convert passwords into unreadable characters. Also avoid using passwords, usernames, session tokens, and API keys in URLs where web server logs can capture them, as this provides exploit opportunities to cybercriminals.
• Simplify authentication credentials. The SSL (Secure Sockets Layer) and TLS (Transport Layer Security) cryptographic protocols produce random access tokens in the username fields of HTTP basic authentication during API requests. If you use HTTP 2, your API servers can avoid handshakes on subsequent requests.
• Document request timeframes. Program your API servers to compare the current time to the time of API requests and accept requests only if they occur within a reasonable timeframe. This prevents brute force attacks on your API server.
• Limit access to HTTP services. Just as OAuth 2 assists with Web APIs, it’s also helpful for protecting REST APIs. The protocol limits third-party access by orchestrating approvals between resource owners and HTTP services.

It’s also a good idea to validate request parameters before requests reach the application logic. Remember to add strong validation checks and reject requests immediately if validation fails.

API Gateways Offer Extra Layer of Security

API gateways can also provide a layer of security for your APIs. As you develop your security policies, there are a few fundamental guidelines to consider. These include using identity access management (IAM) to implement least-privilege-access for creating, reading, updating, and deleting APIs.

Be sure to also log all requests for your APIs as part of your effort to monitor activities by user, by role, and by service. By tracking these records, you can identify requests to the API gateway, the IP addresses from which requests are made, who makes each request, and the date/time of each request.

To help you monitor API security on each of your API gateways, set alarms to watch metrics over a specified period. If a metric exceeds a given threshold, configure the system to send notifications to the pertinent security or compliance policy, which can automatically invoke the necessary security action.

Another critical security aspect to consider is how the resource configurations and relationships of your API gateway compute resources change over time. Also, evaluate if the configurations comply with your internal governance policies, and set up alerts to be notified when a resource violates a compliance rule.