API_Security RoadMap

7 min readJan 16, 2024

What is API_Security?

Application programming interface (API) security refers to the practice of preventing or mitigating attacks on APIs. API`s allows web/mobile apps to send information between each other. APIs work as the backend framework web applications and also for Mobile. APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers.

Just for an Eg: Consider the web application has the HUMAN_BODY and Then API are those which acts like a SKELETON for the HUMAN_BODY

What is API authentication?

API authentication is a combination of technology and process that proves or verifies the identities of users who want access to an API. Specifically, API authentication involves the use of a software protocol to verify that users are who they claim to be when a client makes an API call.

How does API`s Works?

APIs work by sharing data between applications, systems, and devices. This happens through a request and response cycle.

There are 2 major challenges that stand in front of API_Security

1. API_Sprawl

API sprawl is like having too many people doing a similar task in too many different places.For example, API sprawl occurs when you have a bunch of APIs in your organization, often developed by different teams with their own styles and standards.

A drastic increase in the number of APIs has resulted in less visibility of the APIs in your digital estate. The result is challenging to manage and dramatically increases bad actors’ opportunities to take advantage.

2. API_Standardization

The API_Standardization includes the below 5 steps:

API Protection: Go beyond authentication by defining permissions and controlling how much access an individual has when they access an API.
API Governance: IT teams must proactively approach API security through standardization.
API Data Security: By controlling what data is accessible within an API, IT teams can employ an additional layer of protection by ensuring that the API does not release all data to every user that accesses it.
API Discovery: Shadow APIs lurk just outside of sight, and IT teams can’t secure what you can’t find.
API Security Testing: It`s an continuous testing to identify APIs vulnerabilities.

Best Practises to be followed while in the API_Security

Authentication

Don’t use “Basic Auth" as complete layer of security
Use standard authentication instead (e.g., JWT).
Don’t reinvent the wheel in Authentication, token generation, password storage. Use the standards.
Use “Max Retry" and jail features in Login.
Use encryption on all sensitive data.

JWT (JSON Web Token)

Use a random complicated key (JWT Secret) to make brute forcing the token very hard.
Don’t extract the algorithm from the header. Force the algorithm in the backend (HS256 or RS256).
Make token expiration (TTL, RTTL) as short as possible.
Don’t store sensitive data in the JWT payload, it can be decoded easily.
Avoid storing too much data. JWT is usually shared in headers and they have a size limit.

Access

Limit requests (Throttling) to avoid DDoS / brute-force attacks.
Use HTTPS on server side with TLS 1.2+ and secure ciphers to avoid MITM (Man in the Middle Attack).
Use HSTS header with SSL to avoid SSL Strip attacks.
Turn off directory listings.
For private APIs, allow access only from safelisted IPs/hosts.

OAuth

Always validate redirect_uri server-side to allow only safelisted URLs.
Always try to exchange for code and not tokens (don’t allow response_type=token).
Use state parameter with a random hash to prevent CSRF on the OAuth authorization process.
Define the default scope, and validate scope parameters for each application.

Input

Use the proper HTTP method according to the operation: GET (read), POST (create), PUT/PATCH (replace/update), and DELETE (to delete a record), and respond with 405 Method Not Allowed if the requested method isn't appropriate for the requested resource.
Validate content-type on request Accept header (Content Negotiation) to allow only your supported format (e.g., application/xml, application/json, etc.) and respond with 406 Not Acceptable response if not matched.
Validate content-type of posted data as you accept (e.g., application/x-www-form-urlencoded, multipart/form-data, application/json, etc.).
Validate user input to avoid common vulnerabilities (e.g., XSS, SQL-Injection, Remote Code Execution, etc.).
Don’t use any sensitive data (credentials, Passwords, security tokens, or API keys) in the URL, but use standard Authorization header.
Use only server-side encryption.
Use an API Gateway service to enable caching, Rate Limit policies (e.g., Quota, Spike Arrest, or Concurrent Rate Limit) and deploy APIs resources dynamically.

Processing

Check if all the endpoints are protected behind authentication to avoid broken authentication process.
User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders.
Don’t auto-increment IDs. Use UUID instead.
If you are parsing XML data, make sure entity parsing is not enabled to avoid XXE (XML external entity attack).
If you are parsing XML, YAML or any other language with anchors and refs, make sure entity expansion is not enabled to avoid Billion Laughs/XML bomb via exponential entity expansion attack.
Use a CDN for file uploads.
If you are dealing with huge amount of data, use Workers and Queues to process as much as possible in background and return response fast to avoid HTTP Blocking.
Do not forget to turn the DEBUG mode OFF.
Use non-executable stacks when available.

Output

Send X-Content-Type-Options: nosniff header.
Send X-Frame-Options: deny header.
Send Content-Security-Policy: default-src 'none' header.
Remove fingerprinting headers — X-Powered-By, Server, X-AspNet-Version, etc.
Force content-type for your response. If you return application/json, then your content-type response is application/json.
Don’t return sensitive data like credentials, passwords, or security tokens.
Return the proper status code according to the operation completed. (e.g., 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc.).

CI & CD

Audit your design and implementation with unit/integration tests coverage.
Use a code review process and disregard self-approval.
Ensure that all components of your services are statically scanned by AV software before pushing to production, including vendor libraries and other dependencies.
Continuously run security tests (static/dynamic analysis) on your code.
Check your dependencies (both software and OS) for known vulnerabilities.
Design a rollback solution for deployments.

Monitoring

Use centralized logins for all services and components.
Use agents to monitor all traffic, errors, requests, and responses.
Use alerts for SMS, Slack, Email, Telegram, Kibana, Cloudwatch, etc.
Ensure that you aren’t logging any sensitive data like credit cards, passwords, PINs, etc.
Use an IDS and/or IPS system to monitor your API requests and instances.

How to Protect your API_Calls

Use proper API_Gateway and place your API`s behind safe API_Gateways
Use Central OAuth server to issue tokens such as For token based authentications use the servers instead of API_Gateways.
Use JSON tokens for only internal use once used Opaque then for any external access and have key rotation practise.
Not every user required the complete access control for all api`s Implement best access control based on the roles of the API`s.
Trust No 1 Implement ZERO TRUST Model for API`s.
Use Multiple Authentication Mechanisms Not only json token is enough, go ahead with more than 2FA`s
Have a regular practise of performing an Security testing for the API`s on each and every upgradations of the API`s.
Don`t allow the API`s calls to access for all the users, Route it inside the login_page.
Always keep an eye on the place where your API`s are hosted via SIEM tool. This will help you get understanding if any unauthorised attempts towards your API Calls.

International Owasp top 10 API_Standards

Owasp top has released the Latest version of controls for API_Security and below are those.

API1:2023 — Broken Object Level Authorization

API2:2023 — Broken Authentication

API3:2023 — Broken Object Property Level Authorization

API4:2023 — Unrestricted Resource Consumption

API5:2023 — Broken Function Level Authorization

API6:2023 — Unrestricted Access to Sensitive Business Flows

API7:2023 — Server Side Request Forgery

API8:2023 — Security Misconfiguration

API9:2023 — Improper Inventory Management

API10:2023 — Unsafe Consumption of APIs

Few Referal Links for more details

Suggestions are most welcomed,

Please write a mail to Akash.venky091@gmail.com, Also you can follow me here for more updates on Security, Ethical hacking at Akash Venky or contact me @ https://www.linkedin.com/in/akash-h-c-4a4090a7/