API Security — Model

Siddiquimohammad

14 min readMar 16, 2024

In previous article we understood the importance of API security and the common vulnerabilities faced by the APIs

API Security — Introduction

APIs are the entry point for accessing an organization’s functions and data.

medium.com

In this article we will discuss about API SECURITY MODEL :

==> GOVERNANCE

source : APIsec University

The benefits of governance is about establishing consistency. It’s consistency in how your APIs get developed, how they get deployed, how they get tested and everything else.
Setting expectations for your engineering team — what is required? What are those documentation requirements and authentication policies and, and versioning and so forth.
Establishing standard processes for how APIs move from development into production in a consistent way.
And enforcing security to make sure that nothing moves into production that hasn’t gone through the same level of security assessment and vetting.
There are two components to governance.

- There’s an Awareness side — which is about having proper visibility into what APIs do you have, what infrastructure are they running on, what data do they have access to, and what risks do these APIs bring along with them.
- And then there’s a Policy and Process side — which is about how we go about the development of our APIs? How do we go about deploying them? What documentation, what design requirements do we have for these applications?

# AWARENESS

So on the awareness side this is really about knowing your APIs. Gaining a full inventory of your APIs. Why do they exist? Who owns them? How are they documented? What functionality do they offer? Where are they? All of that is granular information.
You want to have a comprehensive view across all your APIs. You want to know your infrastructure, the app architecture, the containers and virtual machines, the databases being connected to the network infrastructure. Have a good understanding of how everything interconnects.
You want to standardize your deployment process so that APIs only get deployed in approved ways with proper validation. Nothing gets out there without following the process. No “shadow” or “rogue” APIs as it’s often called. Frankly, if that’s happening, you’ve got weak governance. There should be no ability for APIs to get into production without your knowledge, without going through these proper channels. The best way to enforce this is through use of an API gateway or marketplace — so you have a central control point where all APIs are being managed properly, and that they’ve gone through the proper validation steps.
Definitely make API documentation mandatory. This is critical for the use of those APIs across the engineering organization, or even with your third party clients and Partners. It also is critical for testing and validation in Security. So make it mandatory and define the documentation requirements and create Design Guides for API development so that these APIs get developed and produced in a consistent and reusable manner.

The next element of awareness is risk and threat modeling. You want to understand the nature of your APIs — what are they, what business flows do they power, what data do they have access to, who has access to it, roles and access controls, etc.. You also want to assess your risk — what vulnerabilities exist, what logic flaws, what access third parties have. You want to make sure you have a proper understanding of the security posture of your APIs.
Then look at the probability of attack. Is this data highly sensitive and highly valuable, or is it fairly benign and low value to an attack? That will help you with your prioritization and understanding the impact — what’s the nature of an exploit, what damage, what kind of loss, what consequences can result?
And then finally, define a response plan. How are you going to respond to an attack when it happens? And how will you address those risks?

So then moving on to documentation.. We run across many organizations where the documentation is patchy or incomplete or non-existent. It’s absolutely crucial to be documenting your APIs properly. It’s not only important for security, it’s also important for development and for enabling the use of those APIs.
The Open API Specification, known as OAS or formerly known as Swagger, is really the industry standard for documenting REST APIs. It looks like machine readable content — typically YAML or JSON. It doesn’t only help integration and enable use of your APIs, but it also aids in security. Testing can be built around your API documentation, and even runtime monitoring can be aided with this documentation.
You want to control your documentation so you know what you’re publishing publicly on the internet has only the documentation that’s required to be published publicly. There are very easy ways to find Open API Specifications on organization websites. So find what those are that you’re publishing. Make sure you’re only publishing what deserves to be out there and that you’re retiring old documentation. This is a huge threat factor — attackers are looking for it. And you want to make sure you’re not keeping content out there that can be used against you.
The documentation itself will define everything about your API — the functionality of the endpoints, the description, where the API exists, the base url, all the endpoints, the payloads, authentication requirements, the input parameters and data types, what methods are supported. And you want to generate this specification as much as possible through automation. You want to instrument your code repost to automatically generate this API specification. Insert the necessary comments and details into the repost to make sure that that documentation comes out as complete as possible.

And just to show you what it can look like, on the left hand side is the raw YAML, or JSON, of a Swagger. There are plenty of Swagger parsers or Open API Spec parsers, which will turn that into what you’ll commonly see on API portals that you might employ on your own public website.
It will help a consumer of your API understand in plain English and visual interfaces what your API does. But over on the left hand side, you’ll see what the machine readable versions of these documentations look like.

# POLICY

From a Design Guide perspective — you really do want to establish standards for your organization — how you will authenticate users, what type of authentication, where you use different types of authentication.
You want to define authorization, how you control who has access to what, and where you will enforce that.
Even things like naming conventions — typically you want your URLs to be nouns and the Methods to be the verbs, whether you’re Posting a new record or Putting a new value in or Deleting things — pluralization and hierarchy, language, lack of jargon.
Your error codes should include status codes, reference IDs and human readable messages, but make sure those messages aren’t revealing useful information back to a potential attacker.
If you’ve got an error code, you don’t want to have the error code say, for example, you’re expecting a certain type of data. That’s simply informing an attacker how to attack your API.
Things like versioning — when to increment, when not to. Units and formats and standards.

I poked around and found this on the Atlassian site. Here’s an example of their design guide for authentication.
So every REST API must have, at minimum, basic user authentication, authorization is not handled at the API layer — it’s the responsibility of the application itself. That’s all defined right here in their design guide.

Similarly, they have a section on, on versions.
When do you need a new version, when do you not need a version, what happens to the old versions.
These are the kinds of things you should be thinking about and defining proactively.

==> SECURE API ARCHITECTURE

The diagram above can be used as a blue print for your API ARCHITECTURE.
The more secure your design is, the less vulnerabilities would be flagged during Security assessments.
Secure API architecture involves securing data end to end, which includes security, from a request originating at the client, passing through networks, reaching the server/backend, the response being prepared and sent by the server/backend, the response being communicated across networks, and finally, reaching the client.
The following points should be covered for a Secure API architecture :

Data security in transit/Motion.

Traffic from client →API gateway , API gateway → target backend & API gateway → IAM server should be TLS secured.
Data like API keys , backend target details and certificate details should be encrypted and stored securely by the API management platform.
It should be ensured that TLS is the latest version and supported by the client, API gateway, IAM server and target backend.
The certificate key stores and trust stores should be highly protected and encrypted.
Only authorized users should have access to certificate key stores and trust stores
This will provide protection against Man in the Middle attack & ensure confidentiality.

2. Expose the APIs via an API gateway

API endpoints(backends) should be shielded by an API gateway providing the following protections

- IP access control — makes sure traffic comes in from legit/intended source(client) .
- Web Application Firewall — to protect against OWASP top 10 API
- DDos Prevention — against Denial of Service Attack
- Rate limiting — to block abnormal volumes of traffic in case of brute force/vulnerability scans by an attacker.
- API key validation and management — make sure every request coming from client should consist of an API key which should be generated by API gateway itself and also rotated and stored in a secure way
- Oauth 2.0 / Open Id connect for authentication and authorization by leveraging an external IAM server ( eg: OKTA)
- CORS (cross origin resource sharing) — Implement CORS header to control which domain can access the APIs and prevent attacks like CSRF
-Http security headers — to prevent client side attacks
- Content validation — to make sure only expected content is processed and attacks like content spoofing is protected
- Error handling — to make sure no sensitive information is exposed in error responses
- Http methods/verb validation — to make sure only intended HTTP methods are being accepted eliminating the risk of HTTP verb tampering attack
- Logging and monitoring — for advanced threat protection & detection of security incidents

3 . Restricted and secure access to API gateway/ API management platform:

The API management platform or the API gateway which you choose ( for eg : APIM in azure) should be

→ restricted with strict IAM policies

→ management traffic should be authenticated and over HTTPS

This ensures any unintended changes to the API gateway which can render the architecture vulnerable .

4 . API endpoints ( backend targets ) deployed on secure platform :

If the platform is vulnerable , the API endpoint becomes vulnerable .
If you are deploying your backend target on VM or container platform like Azure Kubernetes Service make sure the platform adheres to security best practices.

5. Checklist

Final part is to review the architecture against the following checklist

# Example : Securely exposing APIs on azure cloud

Using the same SECURE API ARCHITECTURE discussed above , we have exposed an API endpoint on azure . Lets walkthrough the flow :

Client is configured to generate Oauth token from OKTA IAM.
If the client request has all the valid parameters ( client id ,secret, credentials , etc.) then a JWT token is issued to the client by OKTA.
Client triggers a request to api endpoint ( myapi.com) which resolves to WAF IP address .
WAF receives the request and checks the request for any malicious payload.
Depending on the WAF rule , if it detects anything malicious it blocks (if waf on prevention mode ) or logs ( if waf on detection mode)
If WAF checks are passed, traffic is routed to APIM
APIM is the API management platform and acts as the gateway for the API endpoints . It provides all the security protections as discussed in above section .
APIM then validates the token &API Keys then routes the traffic to backend target ingress controller . This routing is done on private subnet via the Azure Vnet .

9. Ingress controller then routes the traffic to API endpoint .

10. WAF, VNET, APIM and AKS cluster are integrated with Azure Sentinel SIEM solution for detecting threats during runtime.

==> SECURE API CODE

Even after exposing the API endpoint securely , an attacker can exploit the API if the code is insecure.
For example :
An attacker authenticated with valid token ( maybe due to weak/poor authentication mechanism) was able to bypass the WAF and sneak through a SQL injection payload ( yes there are lot of techniques to bypass WAF filters which we will discuss separately ) .
### Achieving both the scenarios together is difficult but not impossible so just assume the attacker was skilled and was able to pull this out ###
Okay , so now if there is no input validation at the API endpoint , SQL injection attack would be possible .
And if there is input validation , SQL injection payload will not be processed by the API endpoint thus preventing the attack.
So you see the importance of secure code review , then make sure the following checklist is covered for the TOP 10 API THREATS by performing CODE REVIEWS and if not then get this addressed by developers

==> API SECURITY TESTING

Once you have deployed the API endpoint on a platform ( for eg Kubernetes cluster) , it should be tested for vulnerabilities from an attackers perspective .
This can be done by performing dynamic testing or a comprehensive API Pentesting to point out the loopholes.
This should be carried out in staging environments ( pre production) & the vulnerabilities which are highlighted should be remediated as per priority before going into production .
There are mainly 3 categories for API Pentesting :

Below is an example checklist for API Pentesting ( entire list is actually huge and will be discussed in coming articles)

==> API SECURITY MONITORING

Monitoring is all about understanding how your APIs are performing and operating in production.
We’re looking at Runtime Protection — active protection of the APIs. This includes policy enforcement, requiring authentication of users to access endpoints, and filtering traffic.
Maybe we need a geographic traffic filter. We’re only expecting traffic from a certain region or IP address and so forth.
So that’s an aspect of runtime protection that you can implement.
The next category is Threat Detection.
How do we analyze the traffic to look for things like fraudulent transactions, fraudulent traffic, and distributed attacks coming from lots of different sources that are targeting similar resources — and you want to be alerted to that and make sure you’re controlling it properly.
And enable incident response — you could capture all the traffic, log it all, put it into a repository, and then retrace the steps to understand what happened.
And finally then implement the appropriate mitigating controls for future similar attacks.
And then you want to Validate Controls to make sure that all the controls that you’ve implemented at the gateway, at the firewall, and in the application itself are functioning as designed.
That there aren’t any surprises happening in production that you weren’t expecting. That you’re finding any anomalies or unexpected traffic from going unnoticed and without control.

Now there are really two fundamental approaches to runtime monitoring.
There’s a Proactive Blocking approach, which you’ll find with things like a gateway or a web application firewall. Here’s where you can actually enforce policy. You can define in a gateway that certain endpoints are only accessible with valid authentication — and the gateway actually can perform the authentication. Or with a firewall you may want to implement rate limiting or IP whitelisting — and if the traffic doesn’t match it gets blocked.
The other side is more of a Reactive, like Alerting mode. For monitoring here, you probably want to capture all the traffic, log it, put it into a SIEM (security information and event management) or a log management solution, or a runtime or API threat management tool. The issue here is you may not have enough context in order to make judgements about whether the traffic is legitimate or not.
So you want to get alerted, you want to be notified, you want to be able to retrace steps because the last thing you want to do is block legitimate traffic.
And there may be instances where there’s just simply not enough context to be able to make a yes/no decision on it.
So then implement alerting, and the ability to go back and understand the traffic, and maybe refine the rules for your inline, proactive technologies.

Another benefit of monitoring is to do API Discovery — to actually watch what’s happening on the wire, on your network, to identify APIs that are in use and active on your network.
This can be useful for generating that inventory, for discovering APIs that were undiscovered, for finding undocumented or unknown APIs, or unknown endpoints.
But you need to be aware that this is not necessarily going to give you a complete view. If your goal is a comprehensive inventory of all your APIs, which it should be — to satisfy those governance requirements — you need to look well beyond network traffic monitoring.
This is because APIs may exist within the firewall that are not necessarily seen by your monitoring tool. You should also scan code repositories to look for APIs, or crawling or app testing.
That’s how you’re going to get a comprehensive view. And ultimately you want to enforce that all APIs are being managed centrally in something like an API gateway.

This sums up our discussion . In next Article we will discuss about API security in SDLC