API Security Posture: Everything You Need to Know

API security posture is the state of your APIs observed from a cybersecurity standpoint. Stripped down of all the technical verbiage, it simply denotes how secure your APIs are.

Some studies cite large enterprises being dependent on 25,000+ APIs. That may sound like science fiction, but it’s the digitalized reality we live in today. How can you, or for that matter, anyone, boast a strong security posture in such a reality?

In this article, you’ll learn the criteria against which you can measure your API security posture and what to do to ensure you’re moving toward a more robust and resilient API security posture.

API Security Posture Deserves Your Attention

A robust API security posture means your APIs:

• Don’t suffer from severe and easily discoverable (by threat actors) flaws and bugs
• Can withstand a wide range of attacks, especially those that are widely known and most common
• Are highly functioning interfaces not plagued by disruptive misconfigurations prone to exploitation

When considering API security posture, remember that we can speak about secure APIs only in relative terms. No API (or any other information system) can be entirely foolproof and safe.

For this reason, we must think dynamically about API security posture. Creating a solid posture is not a one-time affair; it’s a continuous endeavor. The goal is contextual and constantly changing, as are the means of achieving it. What is secure at one point may become insecure at another. A new zero-day or update changes the circumstances and creates a new context for evaluating your API security posture.

This evaluation cannot be subjective. You cannot just think your APIs are in good condition without a sound reason. Your belief must be firmly grounded in empirical reality, meaning it must be based on tangible evidence, measurable values, and tests.

In specific terms, your API security posture is measured against the following criteria:

• Accurate and thorough API inventory
• Precise data classification
• Dependable vulnerability management
• Continuous compliance with regulations and security standards

These four are interconnected. Let’s take one infamous data breach as an illustration.

The prominent Australian telco Optus experienced a grave data breach in 2022. A threat actor discovered an internal API’s endpoints lacking authentication, which allowed them to steal the sensitive information of millions of customers.

The insufficient API inventory led to the exploitation of vulnerable endpoints. That resulted in the theft of sensitive personal information. That caused the Office of the Australian Information Commissioner to open an official investigation into suspected noncompliance with the Australian Privacy Principles.

Had the company managed its API security posture better, it would’ve:

• Created a detailed inventory of its APIs
• Discovered the vulnerable API endpoints
• Avoided leaking sensitive data
• Evaded reputation and financial damage for jeopardizing customer privacy

For reference, another similar example was Meta’s GDPR (General Data Protection Regulation) violation, resulting in a $265M fine.

Due to their significance, let’s explore the four API security posture criteria separately.

Know Thyself: The Blessings of an API Inventory

A deficient API inventory is a nightmare for CISOs. It means impaired visibility and a myriad of possible threats creeping underneath the seemingly quiet surface. It’s like a “Jaws” scenario.

Protecting your APIs without having confidence in your API inventory resembles groping in the dark to find your way up old, tall, creaky stairs. It’s not impossible, but it’s, let’s say, quite challenging.

Unfortunately, that seems to be precisely how things are in practice, judging from “The 2022 API Security Trends Report.” The report states that only about half, 51%, of the respondents expressed complete confidence in their API inventories.

Visibility is among the most desired qualities of information systems. It’s knowing what is there to manage and protect. When it comes to API visibility, there are two possible ways to achieve it:

• Through purposed-built solutions that, among others, allow you to discover shadow and zombie APIs, inventory the APIs in use, and automatically update your API inventory
• Through neatly cataloging APIs as early as you start developing them and from the moment you begin using a third-party API

The second method is self-explanatory, but it’s probably rare in practice.

Regarding the first, different tools can use different techniques for inventorying your APIs. For instance, Equixly does it in the following way:

• You upload an OAS (OpenAPI Specification) file of your APIs in JSON or YAML format
• Equixly conducts thorough testing
• The tool returns a patched version of the OAS file if there are discrepancies between the original API definition and the test results, meaning if the tool discovers previously unknown API endpoints, inputs, and outputs

Equixly finds previously unidentified endpoints and inputs by educated guessing based on volumes of data (such as massive wordlists) processed by its machine learning engine. It discovers undocumented outputs by looking at the responses the APIs return.

It’s a Sensitive Topic: Data Classification

Precise data classification answers the question: What kind of data does an API endpoint operate with? More specifically, it means:

• Knowing which API endpoints transfer sensitive data, such as personally identifiable information (e.g., name and social security number) and personal information (e.g., IP address and location)
• Applying appropriate security measures to protect each API endpoint according to the sensitivity of the information it transfers

An imperative when implementing data classification is to test for sensitive data transferred in URLs. Sensitive data transferred in URLs can be at risk because proxies, servers, browsers, and API gateways typically log/save the information that passes through them and can inadvertently expose it to prying eyes.

One solution to this problem is to include sensitive information in the headers. However, this solution has limitations: each server type—Apache, Tomcat, Nginx, IIS, and Node—enforces a restricted header size, which can prevent you from including all the data you need.

Another solution is to encrypt sensitive data in URLs. Encrypting sensitive data at rest and in transit is an essential security requirement.

However, encryption is not enough to ensure the protection of sensitive data. You must add other security measures to make threat actors’ lives even more difficult.

An API endpoint may leak other users’ sensitive information or return much more data than it should. The security researcher Eaton Zveare recently disclosed a vulnerability in an email-sending API of Toyota Tsusho Insurance Broker India. The API returned a log containing excessive data, including a base64 encoded password that later helped him access sensitive customer data such as personal information and purchased insurance policies.

To protect against excessive data exposure, you must take proper steps as early as in the development phase. Your APIs must be secure by design, meaning they must restrict the data the endpoints return— return only the most necessary—and do not rely on user interfaces for data filtering.

To guarantee that you consistently apply this principle across the board, you must integrate security into SDLC (Software Development Life Cycle) and continuously test your software for excessive data exposure from the first line of code to going live to the next update.

In addition, it’s essential to add strong authentication and authorization methods—such as OAuth2 and encrypted JWTs (JSON Web Tokens)—to API endpoints that are supposed to transfer sensitive data. Again, even then, you need to monitor and test your API regularly for possible authentication and authorization omissions, for these are among the most common and severe API vulnerabilities.

What’s Hiding in the Woods: Vulnerability Management

When it comes to vulnerability management, you can never go wrong with following the OWASP API Security Project. OWASP is one of the most authoritative organizations in cybersecurity, especially web application security, so you know you are on safe ground when relying on its research and findings.

The fruits of the API Security Project are two top ten API security risk lists published in 2019 and 2023. A security testing solution that helps you manage your API vulnerabilities must cover the most recent list of the OWASP Top 10 API Security Risks.

However, effective vulnerability management must continue beyond detecting familiar patterns that fit into the OWASP API Security Top 10. There’s so much talk about business logic vulnerabilities nowadays, and it’s completely justified.

Business logic vulnerabilities are also known as logic flaws and application logic vulnerabilities. They’re notoriously hard to detect because they’re not typical security flaws. They spring from API developers’ and designers’ assumptions about how users and clients will interact with the APIs. And they’re entirely “invisible” if you’re not looking specifically for them.

For instance, the assumption that users will interact with an application reliant on APIs exclusively through the web interface is an example of a logic flaw. If developers put all their hope in client-side controls, threat actors can use a tool like Burp Suite to avoid security controls and manipulate the input–output process.

An API suffers from a logic flaw when it reacts unusually to an unexpected input, leaving room for a threat actor to circumvent any security constraints in place by abusing the API’s logic itself. Security solutions that test your API for this vulnerability type do precisely that: interact with it in ways it was not intended to be used to induce an unexpected behavior that leads to a security crack.

To avoid logic flaws, your developers must document their assumptions of the API’s modus operandi. In addition, you should test for logic flaws long before production.

Law-Abiding Citizens: API Compliance

Compliant APIs are built and maintained according to generally accepted security standards and region-dependent regulations.

PCI DSS (Payment Card Industry Data Security Standard) is an example of a general security standard. It is issued by PCI SSC (Payment Card Industry Security Standards Council). Despite not being a law, it’s mandatory for any organization that works with payment processing information.

APIs are explicitly mentioned for the first time in PCI DSS 4.0 (2022), the most recent version of the standard. That shows the increasing concern over the unsafe development and use of APIs.

PCI DSS includes 12 requirements. PCI DSS 6, the requirement for building and maintaining secure systems and applications, and PCI DSS 11, the requirement for regular testing of security systems and processes, are especially interesting for us here.

These two requirements come down to what we’ve been repeating as a mantra throughout this entire article: integrated security into SDLC and continuous security testing are necessary to protect your APIs in today’s constantly changing conditions.

That implies that not just security professionals but developers, too, are responsible for API security. They must be trained in security testing tools as well as in secure coding practices. This training may prove crucial in avoiding new unique vulnerabilities (zero-days) in bespoke code.

Unlike PCI DSS, GDPR (General Data Protection Regulation) is a law. It applies to EU (European Union) countries but also to non-EU organizations that trade in the EEA (European Economic Area) and collect and process personal data of EU residents.

GDPR’s imperative is to safeguard the integrity and confidentiality of personal data. Like PCI DSS, GDPR instructs organizations to include data protection by design and by default (GDPR, Chapter 4, Article 25) in their applications and, by extension, APIs since the latter operate with PII and other sensitive information.

API security testing helps with compliance because it leads to the discovery of vulnerabilities and misconfigurations that threaten to jeopardize the sensitive data passing through the API. Besides, testing reports can be particularly convenient for ensuring compliance.

Non-compliance with GDPR can lead to criminal charges, though the most common are financial penalties: up to €20M or 4% of a company’s global turnover for highly severe violations and €10M or 2% for less severe violations.

Conclusion

A robust API security posture must be among your top objectives if your organization relies heavily on APIs. To achieve this objective, you need to have a thorough API inventory, precise data classification, reliable vulnerability management, and continued compliance with security standards and regulations relevant to your organization.

Two threads bind these four requirements: continuous security testing and security integrated into development. Ensuring you have these two consistently will give you good prospects for achieving the feat of a robust API security posture.

Contact Equixly to discuss API security and learn how automated continuous testing and machine learning allow you to build a strong API security posture.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.