API Security for Developers

Checklist for Developers for securing APIs

TL;DR — This is an high level checklist for Developers that includes recommendation to securely develop APIs. This checklist focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs). This covers all OWASP Top 10 API security issues. This checklist is applicable across all kind of application that uses APIs for communications.

How does the API working look like

Before understanding the best practices we should first understand why it is important for developers to keep APIs the secure. This is because:

1. From banks, retail and transportation to IoT, autonomous vehicles and smart cities, APIs are a critical part of modern mobile, SaaS and web applications and can be found in customer-facing, partner-facing and internal applications.
2. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers.
3. Without secure APIs, rapid innovation would be impossible.

Broken object-level authorization

• Implement authorization checks with user policies and hierarchy.
• Do not rely on IDs that the client sends. Use IDs stored in the session object instead.
• Check authorization for each client request to access database.
• Use random IDs that cannot be guessed (UUIDs).

Broken authentication

• Check all possible ways to authenticate to all APIs.
• APIs for password reset and one-time links also allow users to authenticate, and should be protected just as rigorously.
• Use standard authentication, token generation, password storage, and multi-factor authentication (MFA).
• Use short-lived access tokens.
• Authenticate your apps (so you know who is talking to you).
• Use stricter rate-limiting for authentication, and implement lockout policies and weak password checks.

Excessive data exposure

• Never rely on the client to filter data!
• Review all API responses and adapt them to match what the API consumers really need.
• Carefully define schemas for all the API responses.
• Do not forget about error responses, define proper schemas as well.
• Identify all the sensitive data or Personally Identifiable Information (PII), and justify its use.
• Enforce response checks to prevent accidental leaks of data or exceptions.

Lack of resources and rate limiting

• Define proper rate limiting.
• Limit payload sizes.
• Tailor the rate-limiting to match what API methods, clients, or addresses need or should be allowed to get.
• Add checks on compression ratios.
• Define limits for container resources.

Broken function level authorization

• Do not rely on the client to enforce admin access.
• Deny all access by default.
• Only allow operations to users belonging to the appropriate group or role.
• Properly design and test authorization.

Mass assignment

• Do not automatically bind incoming data and internal objects.
• Explicitly define all the parameters and payloads you are expecting.
• Use the readOnly property set to true in object schemas for all properties that can be retrieved through APIs but should never be modified.
• Precisely define the schemas, types, and patterns you will accept in requests at design time and enforce them at runtime.

Security misconfiguration

• Establish repeatable hardening and patching processes.
• Automate locating configuration flaws.
• Disable unnecessary features.
• Restrict administrative access.
• Define and enforce all outputs, including errors.

Injection

• Never trust your API consumers, even if they are internal.
• Strictly define all input data, such as schemas, types, and string patterns, and enforce them at runtime.
• Validate, filter, and sanitize all incoming data.
• Define, limit, and enforce API outputs to prevent data leaks.

Improper assets management

• Keep an up-to-date inventory all API hosts.
• Limit access to anything that should not be public.
• Limit access to production data, and segregate access to production and non-production data.
• Implement additional external controls, such as API firewalls.
• Properly retire old versions of APIs or backport security fixes to them.
• Implement strict authentication, redirects, CORS, and so forth.

Insufficient logging and monitoring

• Log failed attempts, denied access, input validation failures, or any failures in security policy checks.
• Ensure that logs are formatted so that other tools can consume them as well.
• Protect logs like highly sensitive information.
• Include enough detail to identify attackers.
• Avoid having sensitive data in logs — if you need the information for debugging purposes, redact it partially.
• Integrate with SIEMs and other dashboards, monitoring, and alerting tools.

Go ahead and check my next blog that cover each category from OWASP API Top 10 to get a code level understanding of issue, impact and patch for the same.

Special thanks for the knowledge shared by OWASP community.

Looking for an API audit? Let’s connect on Twitter