API security should never be taken for granted. With the increasing demand for data-centric projects, companies have quickly opened up to their ecosystem through SOAP or REST APIs.
Application Programming Interfaces (or APIs for short) are the doors to closely guarded data of a company. They’re extremely useful because they allow two different applications to communicate.
On the surface, this is great because they make life much easier for developers, but at the same time, it creates the following challenge: How can we keep the doors open for the API ecosystem and sealed off from hackers at the same time?
API security best practices are the layered controls (encryption, authentication, authorization, monitoring, rate limiting, and gateway-level enforcement) that protect APIs from data breaches and abuse without slowing down legitimate traffic. Below is a checklist of 12 practices for avoiding security risks and securing APIs.
1. Encryption
Be cryptic. Nothing should be in the clear for internal or external communications. Encryption will convert your information into code. This will make it much more difficult for sensitive data to end up in the wrong hands.
You and your partners should cipher all exchanges with TLS (the successor to SSL), whether it is one-way encryption (standard one-way TLS) or, even better, mutual encryption (two-way TLS).
Use the latest TLS versions to block the usage of the weakest cipher suites.
2. Authentication
Don’t talk to strangers. In simple terms, authenticity is real. It means something (or someone) is who they say they are. In the digital world, authentication is the process of verifying a user’s identity. It essentially pulls off the mask of anyone who wants to see your information.
So, you should always know who is calling your APIs. There are several methods to authenticate:
- HTTP Basic authentication where a user needs to provide user ID and password
- API key where a user needs to a unique identifier configured for each API and known to API Gateway
- A token that is generated by an Identity Provider (IdP) server. OAuth 2 is the most popular protocol that supports this method.
At the very least you should use an API key (asymmetric key) or basic access authentication (user/password) to increase the difficulty of hacking your system. But you should consider using OAuth 2 as your protocol of choice for strong, standards-based API authentication.
As my colleague William McKinney points out, some API teams make the mistake of only protecting external-facing APIs – for example, with authentication and authorization security behind an API gateway.
But hackers don’t discriminate between internal and external digital assets. Security vulnerabilities will continue to exist.
This is one reason we are seeing a shift towards the Zero Trust security model, which shifts from applying security at the enterprise perimeter to security at the API layer.
This allows for a more agile application: rather than establishing trust based on where you’re coming from in a network (for example, inside vs. outside), Zero Trust security seeks to authenticate and authorize the identities associated with each API request.
3. OAuth & OpenID Connect
OAuth security delegates authentication and authorization away from your API to a trusted identity provider (IdP), so credentials never touch your service. A good manager delegates responsibility, and so does a well-designed API.
OAuth 2 is a magical mechanism preventing you from having to remember ten thousand passwords. Instead of creating an account on every website, you can connect through another provider’s credentials, for example, Facebook or Google.
It works the same way for APIs: the API provider relies on a third-party server to manage authorizations. The consumer doesn’t input their credentials but instead gives a token provided by the third-party server. It protects the consumer as they don’t disclose their credentials, and the API provider doesn’t need to care about protecting authorization data, as it only receives tokens.
OAuth is a commonly used delegation protocol to convey authorizations. To secure your APIs even further and add authentication, you can add an identity layer on top of it: this is the Open Id Connect standard, extending OAuth 2.0 with ID tokens.
Dive deeper: How to easily secure your APIs with API keys and OAuth
4. Call security experts
Don’t be afraid to ask for (or use) some help. Call in some security experts. Use experienced Antivirus systems or ICAP (Internet Content Adaptation Protocol) servers to help you with scanning payload of your APIs. It will help you to prevent any malicious code or data affecting your systems.
There are several security APIs you can use to protect your data. They can do things like:
- Integrate two-factor authentication
- Create passwordless login, or time-based one-time passwords
- Send out push alerts if there’s a breach
- Protect against viruses and malware
- Prevent fraud
- Let you know if a password is a known password used by hackers
- Add threat intelligence
- Provide security monitoring
The best part is that some of these antivirus systems are free to use. Others offer monthly plans. Premium plans will provide more protection, but you can decide for yourself the type of security you need.
5. Monitoring: audit, log, and version
Be a stalker. Continually monitoring your API and what it’s up to can pay off. Be vigilant like that overprotective parent who wants to know everything about the people around their son or daughter.
How do you do this? You need to be ready to troubleshoot in case of error. You’ll want to audit and log relevant information on the server — and keep that history as long as it is reasonable in terms of capacity for your production servers.
Turn your logs into resources for debugging in case of any incidents. Keeping a thorough record will help you keep track and make anything that’s suspicious more noticeable.
Also, monitoring dashboards are highly recommended tools to track your API consumption.
Do not forget to add the version on all APIs, preferably in the path of the API, to offer several APIs of different versions working and to retire and depreciate one version over the other.
6. Share as little as possible
Be paranoid. It’s OK to be overly cautious. Remember, it’s vital to protect your data.
Display as little information as possible in your answers, especially in error messages. Lock down email subjects and content to predefined messages that can’t be customized. Because IP addresses can give locations, keep them for yourself.
Use IP Whitelist and IP Blacklist, if possible, to restrict access to your resources. Limit the number of administrators, separate access into different roles, and hide sensitive information in all your interfaces.
Dive Deeper into API Security Tools and Best Practices
7. Secure APIs with throttling and quotas
Rate limiting is one of the most effective REST API security controls because it caps how many requests any single client can fire at your backend per second, protecting bandwidth and blunting brute-force attempts. Less is more.
You should also restrict access by API and by the user (or application) to ensure that no one will abuse the system or any one API in particular.
Throttling limits and quotas – when well set – are crucial to prevent attacks coming from different sources flooding your system with multiple requests (DDoS – Distributed Denial of Service Attack). A DDoS can lock legitimate users out of their own network resources.
See also: What are API rate limiting/throttling, API quota, and API bursts?
In a recent API security webinar, we shared how these types of measures can be essential to securing APIs. Because unfortunately, this cautionary tale shows the problem isn’t always coming from outside the enterprise.
8. Data validation
Be picky and refuse surprise gifts, especially if they are significantly large. You should check everything your server accepts. Be careful to reject any added content or data that is too big, and always check the content that consumers are sending you. Use JSON or XML schema validation and check that your parameters are what they should be (string, integer…) to prevent any SQL injection or XML bomb.
9. Infrastructure
Network and be up to date. A good API should lean on a good security network, infrastructure, and up-to-date software (for servers, load balancers) to be solid and always benefit from the latest security fixes.
10. OWASP Top 10
The OWASP API Security Top 10 catalogues the ten most-exploited API vulnerabilities (broken object-level authorization, broken authentication, excessive data exposure, lack of rate limiting, and seven more) ranked by exploitability and impact. Map each item against your own API estate and confirm every API is covered, not just the ones behind a gateway.
11. API firewalling
Your API security should be organized into two layers:
- The first layer is in DMZ, with an API firewall to execute basic security mechanisms like checking the message size, SQL injections, and any security based on the HTTP layer, blocking intruders early. Then forward the message to the second layer.
- The second layer is in LAN with advanced security mechanisms on data content.
The more challenging you make it for cyber attackers to get at your information, the better.
12. API gateway (API management)
Unmanaged APIs are one of modern-day enterprises’ biggest security risks. The average API security breach costs $6.1 million and is expected to nearly double by 2030.
All the abovementioned API security mechanisms can be long to implement and maintain manually. Instead of reinventing the wheel, many enterprises opt for a mature and high-performing API management solution with all these options to save money, time, and resources and increase their time to market. An API gateway helps secure, control, and monitor your traffic.
It serves as a governor of sorts, so an organization can manage who can access an API and establish rules around how data requests are handled.
In addition to more easily securing APIs, an API management solution will help you make sense of your API data to make technical and business decisions on complete, current data. Platforms like Amplify Fusion extend this governance to APIs running outside any single gateway.
13. Continuous API inventory and discovery
A complete, continuously updated API inventory is the foundation of every other practice on this list. Enterprises run an average of 20,000+ APIs across their estate, and security teams typically only know about a fraction of them. The rest are “shadow APIs” (created by individual teams without central governance) and “zombie APIs” (deprecated endpoints that are still live). Both are favorite attack surfaces because they bypass the controls in Sections 1 to 12.
Building an API inventory means continuously discovering APIs in three places:
- In code repositories. Scan for API definitions (OpenAPI, Swagger, or GraphQL schemas) at commit time.
- In traffic. Observe live east-west and north-south traffic to detect endpoints that aren’t documented anywhere.
- In the gateway and management plane. Reconcile registered APIs against what’s actually receiving requests.
Once an API is in the inventory, every control above (authentication, throttling, OWASP review, monitoring) can be applied consistently. A federated API management approach treats the inventory itself as the security boundary, so even APIs running outside a central gateway are governed under the same policy.
14. API security practices at a glance
Use this table to map each practice to the threat it primarily defends against and the implementation priority for a new API program. Practices marked Critical should be in place before an API handles production traffic.
| Practice | Defends primarily against | Implementation priority |
|---|---|---|
| Encryption (TLS, mutual TLS) | Eavesdropping, MITM attacks | Critical |
| Authentication (API keys, OAuth 2) | Unauthorized callers | Critical |
| OAuth and OpenID Connect | Credential theft, weak session control | Critical |
| Authorization (scopes, claims) | Broken object-level authorization (BOLA) | Critical |
| Throttling and quotas | Brute force, DDoS, accidental abuse | Critical |
| Data validation (JSON, XML schema) | SQL injection, XML bomb, malformed payloads | Critical |
| Monitoring, audit, log | Slow-burn breaches, insider misuse | High |
| Share as little as possible | Information leakage via errors | High |
| OWASP API Top 10 coverage | Known systemic vulnerabilities | High |
| API firewalling (DMZ and LAN) | Layer-7 attacks, payload abuse | High |
| API inventory and discovery | Shadow and zombie APIs | High |
| API gateway and management | Unmanaged sprawl, inconsistent policy | High |
| Antivirus and ICAP scanning | Malware in payloads | Medium |
| Infrastructure patching | Known CVEs in stack | Medium |
Bonus: an API marketplace helps enforce API security best practices
Making sure APIs are protected requires a multi-layered defense that starts with centralized API management and extends to identity, traffic, and data controls around every endpoint.
An API marketplace gives you one registry for all your API assets, making it easier to see (and secure) what you have, validate APIs against your security policy, and easily put them into production to drive value.
In the following video, Axway’s William McKinney discusses how an API marketplace built on a federated API management foundation can help enforce your organization’s security practices in a more automated way.
Don’t take API security for granted
It’s unfortunate, but internet threats abound, and hackers are relentless. Implementing a solid API security plan is critical to protecting your information. Crucially, the ultimate best practice is to build API security into the general mindset and process of how APIs are designed and developed.
Axway’s Amplify Platform makes it easier than ever to secure your digital experiences. And with Amplify Engage (previously Enterprise Marketplace), you can unify your distributed APIs under one governance layer, ensuring compliance and consistent API lifecycle management. You’ll be less vulnerable to cyber-attacks, allowing you to focus on what you need to get done.
By combining the right technology with a more deliberate process, building security into the design process from the start, you can uncover and address security threats before they arise.