API security is, unfortunately, a complex topic for many. While the potential solutions are numerous, the possible pitfalls are almost limitless, and what may be a minor issue for one organization can be fundamentally game-changing for another.

Below, we’re going to look at nine common anti-patterns that indicate security issues within an organization or product.

1. Overreliance on API Keys

API keys are foundational elements for authentication, but relying solely on them is inherently a risky proposal.

Firstly, there’s the reality that API keys are not securely designed — they were never meant to be used as the sole form of authentication, and as such, they aren’t really built for the task. These keys can often be easily stolen, leaked, or, in some cases (especially if generated incrementally), outright guessed. An API key is suitable for tracking usage but is poor for security.

There is also the additional reality that keys in their default state lack some critical functionality. There’s not a lot of verification built-in for identity management, and what does exist offers very little in the way of granular access control.

Ultimately, solely relying on API keys is a mistake common with novice developers but frighteningly common even in advanced products.

Best Practices

Instead of relying heavily on API keys as a sole mechanism, combine those keys with additional approaches such as OAuth 2.0 or mTLS. Implement rigorous expiration and rotation policies to ensure that keys which are made public are only useful for a short amount of time. Consider more advanced approaches, such as IP whitelisting or device fingerprinting, to add another layer of security atop the API key process.

2. No Smart Authorization Flows

Authorization flows are another important part of creating a secure system. APIs should have substantially secure authorization mechanisms. If you are only using simple key checks or implicit flows, you are missing a larger body of potential security checks and services, thereby making your product far less secure.

Missing role-based access control (RBAC) and attribute-based access control (ABAC) is a common symptom of this problem, but this can also include overly-permissive API endpoints that operate on simple binary yes or no conditions or key validation from a single server.

Best Practices

Firstly, developers should adopt the principle of least privilege — access should only be allowed where it is necessary, and only in such a way as to facilitate that function. In doing this, developers will naturally need fine-grained access controls. Solutions such as OAuth 2.0, OpenID Connect, and other such systems will allow developers to implement dynamic authorization flows, avoiding the pitfalls of this particular type of security misstep.

3. Improper Encryption: At Rest or in Transit!

Data is the lifeblood of an API, and as such, securing that data should be a foundational concept in any security posture. Unfortunately, it’s quite common for developers to employ encryption insufficiently.

This can take a few different forms. First is lacking encryption either at rest, in transit, or both. This is very obvious, however, and as such, is uncommon in good API products. What is more common, however, is insufficient encryption due to weak or outdated algorithms. Encryption is not a ‘set and forget’ process — what was strong last year is likely weak this year.

There’s also a worryingly common issue of an insecure system undermining a secure system. For instance, having strong encryption at rest and in transit that uses a salting process that uses an insecure methodology could undermine not only the salt but the encryption itself. The graveyard of dead APIs is littered with services that stored data in an outdated encryption standard that was rendered useless due to poor salting.

Best Practices

Developers should first ensure they meet some basic requirements for securing their systems. Basic approaches such as enforcing HTTPS with TLS 1.2+ will help secure encryption in transit. Using high-level encryption such as AES-256 at rest will take care of the rest of the security posture, at least from an active encryption point of view.

More generally, developers should think about what data they collect, why, and what they choose to store. Having fewer data points to secure gives you less of a cryptographic headache. Employing more secure cryptographic key management solutions alongside a better culture of security can also ensure that you have to revisit this issue less commonly.

That said, cryptography is a constant struggle between the system security and the attackers trying to undermine the system, so developers should routinely and completely audit their systems to ensure compliance.

4. Using Outdated or Vulnerable Third-Party Dependencies

In many cases, utilizing a third-party library or framework can significantly accelerate development compared to in-house resources. While this makes third-party systems quite attractive, it unfortunately does introduce a good deal of risk through potential vulnerabilities.

It’s important to audit and update third-party packages. Vulnerabilities in many third-party libraries have caused headaches for adoptees in the API space, from Log4j to OpenSSL. The main takeaway from these experiences is that you can’t simply trust an implementation without fully vetting, reviewing, and auditing it.

Best Practices

Developers should regularly audit their systems and dependencies for vulnerabilities. Wherever possible, up-to-date versions of each dependency should be vetted and utilized, with functions being regularly reviewed and updated as new versions roll out. Unused libraries and dependencies should be removed as fast as possible, as these introduce risks with little to no benefit.

5. No Standard Authorization or Authentication

Having an agreed-upon approach to authorization and authentication is quite important to a development team — it’s often a solid line between a decent security posture and a fundamentally weak one. What’s most important, however, is alignment to that approach.

Inconsistencies around authorization or authentication standards between teams within the same service can lead to significant security issues. Beyond the direct implication — that any given element may or may not be less secure than other elements within the service collection — there is also the reality that the interplay between these systems is not formalized. This can introduce ad hoc solutions and insecure approaches, functions, and systems.

Best Practices

Developers should adopt standard approaches to authorization and authentication, but they should enforce these standards universally. Within a development team, a security contract should state the minimal expectation and the common denominator within the system.

Adopting a standard security approach will lead to more secure development, but will also ensure that each part works well with the others in a commonly defined and understood framework and security apparatus.

6. Lack of Rate Limiting and Throttling

API security isn’t just about ensuring the data is secure. It’s also about ensuring the systems that use that data are healthy. Rate limiting and throttling are critical to that strategy, allowing you to prevent abuse and API overload by filtering out traffic and limiting the scope and size of requests.

Not having rate limiting and throttling exposes your service to some pretty intense (and easily avoidable) attack vectors. From denial-of-service attacks to credential stuffing and brute-force-style campaigns, these attacks leverage overly permissive systems to overflow and overload. The easiest response is to limit these systems and limit the potential damage.

Best Practices

Implementing basic rate limiting and throttling should be the first step for any serious development. Taking this a step further, providers can adopt more advanced strategies to take on a granular approach. Request quotas, per-IP limits, and exponential backoffs allow you to increase security depending on various factors rather than just instituting a blanket restriction. Configuring alerts for unusual spikes in traffic can add a layer of responsiveness, allowing you to invest in response teams that mitigate spikes in attack vector utilization when necessary.

7. Insufficient Data Filtering

APIs return data — that’s what they’re built to do. Returning too little data is problematic for many reasons, but even more problematic is when an API returns too much data. APIs should only return what is necessary to accomplish a task, but too often, APIs give you access to the entirety of data in any form and function you could want.

This is foundationally dangerous for several reasons. Firstly, poor data filtering can expose sensitive user information in API responses. Improper output filtering could expose database structures, security schemas, internal logs, and much more.

Even abstracting away the very real risks of insufficient filtering, the reality is that it represents a larger issue — teams that deploy insufficient data filters are most likely insecure by default and have a weak security position. Security-first is both an approach and a mindset, and as such, this is an area that stands out as a huge red flag.

Best Practices

Firstly, APIs should only return what is absolutely necessary to provide basic functions. Using schema validation to restrict response fields can be helpful in this regard, as can data masking, which filters sensitive information from returned functions.

Technologies like GraphQL can surface much data with a single request. However, API providers should make sure only the data that could be useful or necessary is surfaced, even if the access itself is relatively uncontrolled.

As with most items on this list, regular security auditing is also necessary. Regularly ensuring that your service is returning what you expect it to — and only what you expect — can help ensure you don’t overexpose data and render your systems insecure.

8. Poor Logging and Monitoring

While it’s not a security practice in the same way that encryption is, logging and monitoring are vital for helping to establish and maintain a secure environment. Logging and monitoring help to detect security incidents in real-time, giving actionable data through which you can mitigate concerns and reduce exposure.

When companies do not adequately deploy logging and monitoring, a series of issues crop up. Firstly, there are no real audit trails for API requests, making it harder to mitigate long-term issues. Pair this up with the lack of immediate logging and error tracking, and you have a recipe for security lapses that can’t be tracked or fixed at scale.

Best Practices

Developers should log as much as possible while ensuring that these logs are maintained securely. Logging authentication success and failures, excessive requests, and other unusual patterns can ensure you have a top-level view of what’s happening in your system. Without this data, you have few options for tracking issues at scale and mitigating them meaningfully.

More advanced systems can help you take this to the next level. Utilizing heuristics and other active logging and observability systems can help develop an understanding of immediate threats and the overall health of your platform.

9. Improper CORS Configuration

Improper CORS configuration is a foundational error that is unfortunately very common. CORS settings allow you to define what domains access your APIs, allowing you a great amount of control over how data flows in and out of your services. Improper CORS misconfigurations can be general, such as allowing requests from “*”, or all origins, which is overly permissive.

However, this can also include more subtle issues, such as improper restrictions around methods and headers, or allowing credentialed requests that bear the correct auth tokens but come from untrusted origins. These types of issues are frighteningly common, and they can undermine even the most otherwise secure implementations.

Best Practices

Providers should ensure that domains are restricted to “trusted” domains. Even within this context, zero-trust architectures are arguably the most secure since they vett and secure even seemingly valid traffic.

Using strict allowlist politics for methods and headers and logging and monitoring any CORS policy violations is also an excellent best practice, as it ensures high observability and prevents issues from flying under the radar.

Mitigating API Security Anti-Patterns

While these issues might seem relatively basic, they are unfortunately quite common. While a singular issue is significant on its own, it’s usually indicative of other underlying problems. Accordingly, developers should consider their holistic security posture in the context of these and other issues. Security is not a one-and-done process — it requires constant vigilance and awareness.