OWASP API Security Top 10 and Beyond!

Course Objectives:
1. Introduce OWASP, the API Security Project, and the changes from the OWASP API Security 2019 to
2023.
2. Prepare students to pass the Certified API Security Analyst (CASA) exam.
3. Develop a strong foundation in the following API security risks:
1. Broken Object Level Authorization (API1:2023)
2. Broken Authentication (API2:2023)
3. Broken Object Property Level Authorization (API3:2023)
4. Unrestricted Resource Consumption (API4:2023)
5. Broken Function Level Authorization (API5:2023)
6. Unrestricted Access to Sensitive Business Flows (API6:2023)
7. Server Side Request Forgery (API7:2023)
8. Security Misconfiguration (API8:2023)
9. Improper Inventory Management (API9:2023)
10. Unsafe Consumption of APIs (API10:2023)
4. Help secure the APIs of the Internet and prevent API-related data breaches.
5. Prepare students with additional resources for continued learning and growth in API security.

About

OWASP API Security Top 10 – Summary Notes

About OWASP:
• Nonprofit foundation improving application security.
• Founded: Dec 1, 2001.
• Known for: Top Ten lists, open-source tools, community projects.
API Security Top 10:
• Focus: Most critical security risks for APIs.
• Launched: Dec 2019.
• Founders: Erez Yalon & Inon Shkedy.
Why the API Top 10 Was Created:
1. Rapid Rise of APIs:
• APIs enable fast, flexible software integration.
• Organizations use external APIs (maps, payments, etc.) instead of building in-house.
• APIs drive data exchange and are major business enablers.
2. Major Gap in Security:
• Traditional tools (WAFs, scanners) can't detect API-specific issues.
o APIs left organizations exposed to data breaches.
3. New Leading Attack Vector:
• API vulnerabilities allow attackers to bypass traditional defenses.
 • Insecure APIs can directly expose sensitive data.
How the Top 10 is Compiled:
Source of Data (2023):
• Based on public data (bug bounty reports, news articles).
• No data submitted during the 2022 call for data window.
• Research similar to the 2019 approach.
Limitations of Data:
• Bug bounties bias certain findings.
• Limited representation of all real-world APIs.
• Public incidents may lack technical depth or not be fully reported.
Notable API Security Incidents (2018–2023):
• 2018 – USPS Data Leak
• 2019 – Venmo Public API Scraping
• 2021 – Peloton, Parler, LinkedIn API Leaks
• 2022 – Coinbase, Optus, Toyota API Breaches
• 2023 – EatonWorks Toyota Disclosure, T-Mobile API Exposure

Update to 2023
Two Removed
• Injection
o Still a threat, but less prevalent due to improved mitigation (e.g., WAFs, input validation).
o Not as prominently represented in recent API breaches or bug bounty data.
• Insufficient Logging and Monitoring
o A classic OWASP concern, but rarely tied directly to API-specific incidents or public disclosures.
o Removed to make room for emerging, more pressing API-specific risks.
Three Remain
• Broken Object Level Authorization (BOLA)
o Continues to be one of the most common and critical API security issues.
o Frequently observed in real-world breaches and bug bounty reports.
• Broken Function Level Authorization (BFLA)
o Also remains widespread and impactful.
o Indicates persistent authorization issues in API implementations.
• Security Misconfiguration
o A broad and persistent risk that covers a variety of misconfiguration scenarios.
o Unlikely to ever leave the list due to its wide scope.
Four Renamed
• Broken User Authentication → Broken Authentication
o Simplified name reflects a broader focus on all types of API authentication, not just user-related.
• Improper Assets Management → Improper Inventory Management
o Terminology updated for better clarity and alignment with industry language.
 o "Inventory" covers a broader set of resources than "assets.
Five New
1. Server Side Request Forgery (SSRF)
o New to the API Top 10, but included in the OWASP 2021 list.
o Added based on survey data rather than incident frequency.
2. Unsafe Consumption of APIs
o Highlights risks from blindly trusting and integrating third-party or partner APIs.
3. Broken Object Property Level Authorization (BOPLA)
o New category combining aspects of:
▪ Excessive Data Exposure
▪ Mass Assignment
4. Unrestricted Resource Consumption
o Addresses risks like DoS attacks via unbounded API usage.
5. Unrestricted Access to Sensitive Business Flows
o Focuses on abuse of logical business operations exposed via APIs.

OWASP Top #1
API1:2023 – Broken Object Level Authorization (BOLA)
Overview
• Most common and severe API vulnerability.
• Occurs when authorization checks are missing or improperly implemented.
• Users should only be able to access resources they own.
• Attackers can access other users’ data by manipulating object IDs in API requests.
Attack Vector
• Attackers manipulate object identifiers (e.g., IDs in paths, queries, headers, or payloads).
• These IDs can be:
o Integers: /api/user/1
o Strings: /admin/settings/account/bman
o Tokens: ?user_id=aE1230000token
• By guessing or enumerating other IDs, attackers can access unauthorized resources.
Security Weakness
• Access control is complex and can be inconsistently implemented.
• Even with an access control framework in place, developers might skip enforcing it on some endpoints.
• These flaws are hard to detect with automated tools.
Impacts
• Data leakage, manipulation, or deletion.
• Can lead to full account takeover.
• Exposure of sensitive or personal data.
Example
• Authenticated user (Bruce) requests:
• GET /api/v3/users?id=2727
Returns Bruce’s info.
 • Bruce then tries:
• GET /api/v3/users?id=2728
Returns Harvey Dent’s info → BOLA vulnerability.
• BOLA checks can be done by replacing resource IDs in various request types:
• GET /api/user/1 → /api/user/2
• POST /company/account/Apple/balance → /company/account/Google/balance

Common Patterns
• Resources might be organized:
o Per user: /user/1/profile
o By group: /group/45/settings
o Hybrid: /group/45/user/3/settings
• BOLA exists when a user can access a resource they don’t own or shouldn’t see.
Preventative Measures
• Enforce authorization checks for every resource access.
• Use user policies and role-based access control (RBAC).
• Avoid predictable resource IDs:
o Prefer UUIDs/GUIDs over sequential numbers.
• Build automated authorization tests:
o Prevent deployment if tests fail.
• Ensure checks happen in every function that uses client-provided input to retrieve records.

OWASP Top #2
API2:2023 – Broken Authentication
What It Is
Broken authentication refers to flaws in the API authentication process. Authentication is used to verify the
identity of users, whether they are people, devices, or systems. Common methods include usernames and
passwords, tokens, and multi-factor authentication.
Causes
• No or weak authentication mechanisms
• Incorrect implementation of authentication logic
• Complexity and misunderstanding of authentication by developers
OWASP Descriptions
Attack Vector
Authentication endpoints are public and commonly targeted. While some exploits require advanced skills,
tools for these attacks are readily available.
Security Weakness
Developers often misunderstand authentication boundaries. Implementation is complex and prone to error.
Issues are easy to detect and exploit.
Impact
Attackers can take over accounts, access sensitive data, and perform unauthorized actions. Their actions often
appear legitimate to the system.
Common Vulnerabilities
Weak Password Policy
• Allows weak passwords
• Permits brute force attempts
• No confirmation for password or email changes
• Credentials exposed in URLs
• GraphQL allows multiple login attempts per request
• Sensitive requests lack authentication
Credential Stuffing
• Repeated attempts using credentials stolen from breaches
• Exploits systems with no protection against repeated login attempts
Predictable Tokens
• Tokens generated in predictable ways (e.g., incremental IDs)
• Can be guessed or recreated by attackers
Misconfigured JWTs
• Accept unsigned tokens
• Ignore expiration fields
• Leak sensitive data in token payload
• Use weak keys for signing
Key Concepts
• Authentication is typically the first line of defense in APIs
• Stateless APIs require token-based systems, which add complexity
• Weak token generation increases risk of token forgery or hijacking
• Registration and password reset systems are common targets
• Example: 6-digit password reset code with no rate limiting allows brute force in 1 million tries
Preventative Measures
• Understand and document all authentication flows (mobile, web, links)
• Know the difference between OAuth, API keys, and authentication
• Use proven libraries and standards for auth and token handling
• Apply brute force protections to password reset and recovery endpoints
• Require re-authentication for sensitive actions
• Implement multi-factor authentication
• Add protections against brute force, dictionary, and credential stuffing attacks
• Enforce account lockout or CAPTCHA after repeated failures
• Ensure strong password policies
• Do not use API keys for user authentication—only for identifying API clients

OWASP Top #3
API3:2023 – Broken Object Property Level Authorization (BOPLA)
What It Is
BOPLA is the combination of two 2019 OWASP API vulnerabilities:
• Excessive Data Exposure
• Mass Assignment
Both involve failures in object property level authorization, which is why they are now addressed together.
Key Concepts
Excessive Data Exposure
• Happens when an API returns entire data objects, including sensitive fields.
• Often occurs when the provider expects the client to filter out unnecessary data.
• Example: Requesting a user’s name and receiving full details like DOB, email, and contacts.
Mass Assignment
• Happens when user input can add/change internal object properties the user shouldn't have access to.
• Example: An attacker adds "isAdmin": true to a user creation request and becomes an admin if input is
not sanitized.
OWASP Attack Vector Description
• APIs (especially REST) often expose full object properties.
• GraphQL may need specially crafted queries, but tools can automate the process.
• Attackers use API responses and fuzzing to find exploitable properties.
OWASP Security Weakness Description
• Sensitive data exposure is often detectable just by inspecting responses.
• Fuzzing and crafted requests help identify unauthorized properties that can be changed.
• Sometimes side-effects (not direct responses) reveal successful manipulation.
OWASP Impacts Description
• Can lead to data disclosure, corruption, or loss.
• May allow privilege escalation or even account takeover.
Summary
• BOPLA merges Mass Assignment and Excessive Data Exposure due to their shared root cause: failures
in validating access to object properties.
• Two main vulnerability patterns:
o Users can view sensitive properties they shouldn't.
o Users can modify properties they shouldn't.
Testing Techniques
• Review API responses for sensitive or excessive information.
• Analyze API documentation to identify sensitive parameters.
• Add extra parameters to requests and observe responses or side effects.
Preventative Measures
• Always validate that users can access only the object properties they're authorized for.
• Avoid using generic serialization methods like to_json() or to_string().
• Avoid automatic binding of input into internal objects (i.e., mass assignment).
• Restrict updates to only explicitly allowed object properties.
• Use schema-based response validation to define and enforce what each API method can return.
• Keep response data minimal and aligned with business/functional requirements.
OWASP Top #4
API4:2023 – Unrestricted Resource Consumption
What It Is
Unrestricted Resource Consumption occurs when an API provider fails to enforce limits on how much of their
system’s resources a client can consume.
This can lead to Denial of Service (DoS), increased operational costs, and degraded service quality.
Updated version of API4:2019 – Lack of Resources and Rate Limiting.
OWASP Attack Vector Description
• Exploitation is simple—just send normal API requests at high volume.
o Can be launched from:
▪ A single local computer or
▪ Cloud infrastructure for higher impact.
▪ Automated tools exist to simulate high traffic and cause DoS.
OWASP Security Weakness Description
• Many APIs lack limits on:
o How often a client can call an endpoint.
▪ How much data can be returned or processed.
o Attackers can:
▪ Use crafted requests (e.g. large page sizes, GraphQL batching).
▪ Monitor response times or payload sizes to optimize impact.
o Attackers might not know exact cost impact but can infer it based on cloud pricing models.
OWASP Impacts Description
• Denial of Service (DoS) due to CPU, memory, or file descriptor exhaustion.
• Increased infrastructure costs, especially with auto-scaling environments.
• Service degradation for other users.
• Potential for unexpected financial impact (e.g. storage, API gateway processing, bandwidth).
Vulnerable API Scenarios
An API is vulnerable if it lacks or misconfigures limits on:
• Execution timeouts
• Allocable memory
• File descriptors
• Number of concurrent processes
• Upload file size
• Number of operations in a request (e.g. GraphQL batching)
• Records per page in response
• Spending limits with third-party services
Summary
• Every API call has a technical and financial cost.
• Lack of restrictions increases the risk of:
o DoS/DDoS attacks
o High infrastructure bills
o Poor user experience
 • Rate limiting is essential for:
o API availability
o Cost control
o Business model enforcement (e.g. tiered usage limits)

OWASP Preventative Measures

• Use Docker to limit:
o Memory
o CPU
o File descriptors
o Number of processes/restarts
• Implement rate limiting (per time period per client).
• Notify clients when limits are exceeded and when they’ll reset.
• Validate and limit:
o Query parameters (e.g. limit=1000)
o Payload sizes (strings, arrays)
• Enforce limits on:
o Upload sizes
o Number of records per request
o Total operations per request

OWASP Top #5
API5:2023 Broken Function Level Authorization (BFLA)
BFLA occurs when APIs expose functions that do not have proper access controls, allowing users to perform
actions they shouldn't be able to.
Key Concepts
• BFLA is about unauthorized access to functionality, not just data.
• Common issue in APIs with multiple roles (e.g., admin, user, partner).
• Exploits include altering or deleting data, privilege escalation, or using HTTP methods like DELETE when
not allowed.
• An attacker may perform actions meant for other user roles if access controls are missing or
misconfigured.
OWASP Attack Vector
• Attackers send legitimate requests to functions they shouldn't have access to.
• Exploitation is easier in APIs due to their structured nature and predictable access patterns.
OWASP Security Weakness
• Authorization logic is often configured at code or system level.
• Confusion can arise due to role hierarchies and complexity.
• APIs often expose these flaws due to improper function-level access validation.
OWASP Impacts
• Attackers can access restricted functions like user management or data modification.
• Potential consequences: data loss, corruption, service disruption, or account takeover.
Examples
• Using a DELETE request instead of PUT and receiving a message like “This is an admin function” could
reveal a vulnerable admin endpoint.
• Exploiting different endpoints or HTTP methods without proper controls may allow access to
administrative features.
OWASP Preventative Measures
• Implement a centralized authorization mechanism applied to all business functions.
• Default to denying access and require explicit grants based on user roles.
• Review all API endpoints and their expected access patterns based on business logic and group
hierarchies.
• Ensure all admin controllers inherit from a secure base controller enforcing proper checks.
• Regular controllers with admin functions should enforce authorization based on roles and groups.

OWASP Top #6
API6:2023 – Unrestricted Access to Sensitive Business Flows
Overview:
This vulnerability arises when API-driven business workflows can be accessed and abused without proper
restrictions, allowing attackers to disrupt legitimate user activity or exploit application functionality for
personal gain.
Real-World Example:
An attacker automates purchase requests to deplete stock of a product (e.g., scalping PS5s), preventing others
from buying it.
OWASP Attack Vector Description:
• Exploitation involves understanding how a business model operates through its APIs.
• Attackers identify sensitive flows and automate access to them.
• The goal is often business disruption, not technical compromise.
OWASP Security Weakness Description:
• Root cause is lack of holistic understanding of API workflows and how they impact the business.
• Attackers reverse-engineer workflows by analyzing API endpoints and their relationships.
• Even with mitigations, attackers may bypass protections if they are weak or inconsistent.
OWASP Impact Description:
• Usually no direct technical damage.
• Business-level impacts like:
o Blocking legitimate purchases.
o Manipulating internal economies (e.g., in-game currency inflation).
o Spamming or abusing expected functionality.
Summary:

• API "flows" are chains of requests that perform actions.

o If unrestricted, attackers can:
▪ Spam systems.
 ▪ Lock out real users.
▪ Drain stock or exploit resources.
o Example defense: CAPTCHA on checkout slows down bots.
OWASP Preventative Measures:
Business Layer:
• Identify sensitive flows that could harm the business if abused.
Engineering Layer:
• Choose protective mechanisms:
o Device Fingerprinting: Block or challenge headless browsers or suspicious devices.
o Human Detection: Use CAPTCHA, biometrics, or typing pattern analysis.
o Behavioral Analysis: Flag users who perform actions unrealistically fast (e.g., add-to-cart +
checkout in <1 second).
o Block Malicious Sources: IP blocking for Tor exit nodes or known proxy services.
o Secure Machine-to-Machine APIs: These often lack protection and are high-value targets.

OWASP Top #7
Intro
• SSRF happens when an attacker controls what remote resources an API server retrieves.
• Input like a URL is accepted and fetched by the server without proper validation.
• It can expose private/internal data, scan internal networks, or even execute remote code.
OWASP Attack Vector
• Attacker finds an API endpoint that accepts and fetches a client-supplied URI.
• Easier to exploit when the server returns the fetched data (In-Band SSRF).
• Blind SSRF (no response to attacker) requires more creativity and monitoring.
OWASP Security Weakness
• Common due to design patterns that accept user-provided URIs.
• Lack of input validation and improper parsing lead to vulnerability.
• Blind SSRF is harder to detect since responses aren’t visible.
OWASP Impacts
• Internal network scanning, bypassing firewalls, data disclosure.
• Potential for DoS or abusing the server as a proxy.
Summary
• SSRF lets attackers make the server fetch attacker-controlled URLs.
• Two types:
o In-Band SSRF: Server returns fetched content to attacker.
o Blind SSRF: Server makes request, but no feedback is returned. Detectable using external
monitoring tools like Burp Collaborator or webhook.site.
Example Attack
{
"inventory": "<http://localhost/secrets>"
}
• Could reveal internal tokens, secrets, or sensitive services.
Out-of-Band SSRF
• Uses an external domain (e.g., webhook.site) to confirm request behavior when server doesn’t return
anything.
Preventative Measures
• Isolate resource-fetching logic and prevent internal access.
• Enforce allow lists for:
o Remote origins
o URL schemes (http, https) and ports
o Expected content/media types
• Disable HTTP redirects.
• Use robust URL parsers.
• Sanitize and validate all input.
• Avoid sending raw responses to clients

OWASP Top #8
Security Misconfiguration
Intro
API8:2023 Security Misconfiguration refers to a broad range of vulnerabilities in the systems hosting APIs.
Misconfigurations can threaten confidentiality, integrity, and availability, with consequences ranging from
information disclosure to full data breaches.
Attack Vector
Attackers look for unpatched flaws, common endpoints, or exposed files/directories to gain unauthorized
access or knowledge of the system.
Security Weakness
Misconfigurations can occur at any level of the API stack—network, server, or application. Tools exist to detect
issues like legacy features, default credentials, or unnecessary services.
Impacts
These flaws can expose sensitive data, internal system details, or even allow complete server compromise.
Common Misconfigurations
• Misconfigured Headers: Can leak tech details (e.g. X-Powered-By), weaken security (X-XSS-Protection:
0), or leak usage data (X-Response-Time).
• Lack of Input Sanitization: Enables uploading malicious payloads or behavior manipulation.
• Unnecessary HTTP Methods: Increases risk of exploitation.
• Default Accounts/Credentials: Easy way in for attackers.
• Weak or Missing Encryption: Makes MITM attacks viable, especially without TLS.
Examples
• Uploading a script via a file upload endpoint and accessing it through a public URL could lead to remote
code execution.
• X-Response-Time inconsistencies can reveal existing records via response time analysis.
Detection
Web app scanners like Burp Suite, OWASP ZAP, Nessus, Qualys, and Nikto can identify security
misconfigurations by inspecting headers, cookies, encryption, and parameters. Manual inspection is also
possible if you know what to look for.
Preventative Measures
• Implement a repeatable hardening process.
• Regularly review and update configs across the API stack (e.g. orchestration files, cloud services).
• Continuously assess configuration effectiveness.
• Use TLS for all communications, even internally.
• Restrict HTTP methods—disable any that aren’t required.
• For browser-based APIs:
o Apply proper CORS policies.
o Include security headers.
• Limit accepted content types to necessary formats.
• Ensure consistent request processing across all HTTP servers to prevent desync issues.
• Define and enforce API response schemas to avoid leaking stack traces or system info.

OWASP Top #9
PI9:2023 Improper Inventory Management
Introduction
Improper Inventory Management refers to the exposure of non-production or unsupported API versions.
These versions are often less secure, creating a gateway for attackers to exploit vulnerabilities that would
otherwise be protected in production environments.
OWASP Attack Vector
Attackers gain unauthorized access by:
• Targeting old or unpatched API versions
• Exploiting weaker security on test/dev environments
• Accessing sensitive data via third parties with unnecessary privileges

OWASP Security Weakness

• Outdated documentation makes it harder to identify or patch vulnerabilities
• Lack of asset inventory and poor retirement strategies result in unmonitored, exposed endpoints
• Modern architectures (e.g., microservices, Kubernetes) increase exposure
• Discovery methods include Google Dorking, DNS enumeration, Shodan, etc.

OWASP Impacts
• Unauthorized access to sensitive data
• Potential for full server compromise
• Attackers may find older API versions tied to live databases or use deprecated endpoints to exploit
known bugs or admin features

Summary
Improper Inventory Management occurs when:
 • Unsupported or development APIs remain publicly accessible
• These versions are often unpatched, less secure, and a vector for deeper vulnerabilities
Leads to:
• Excessive data exposure
• Information disclosure
• Mass assignment vulnerabilities
• Improper rate limiting
• API injection

Detection Methods
• Analyze outdated documentation, changelogs, and repository history
• Look for versioned endpoints like /v1/, /v2/, /alpha/, /beta/, /uat/, /test/
• Check if deprecated endpoints (e.g., apiv1.org/admin) still respond
• Inspect API versioning through:
o Paths: /api/v2/accounts, /v3/
o Headers: Accept: version=2.0
o Query parameters or body: ?ver=2, {"ver":1.0}

Non-Production Indicators
• Subdomains: api.test.target.com, beta.api.com, api.uat.target.com
• Paths: /api/private, /api/partner, /api/test
• These are typically less monitored, often connected to real data, and not patched

OWASP Preventative Measures

1. Inventory all API hosts
o Include version, environment (prod/dev/test), and access scope
2. Track integrated services
o Note roles, data exchanged, and sensitivity
3. Document API behavior
o Authentication, errors, rate limits, CORS, endpoints, parameters, and responses
4. Automate documentation
o Use open standards and integrate into CI/CD
5. Restrict documentation access
o Only authorized users should view API docs
6. Apply security controls to all versions
o Use API firewalls on all environments, not just production
7. Avoid production data in non-production environments
o If necessary, apply equal security controls
8. Perform risk analysis on older versions
o Consider backporting fixes or forcing migration to updated versions
OWASP Top #10
API10:2023 Unsafe Consumption of APIs
Intro
• API10:2023 is unique among the OWASP API Security Top 10 because it focuses on API consumers
rather than providers.
• Unsafe consumption is essentially a trust issue. Third-party API data should be treated with the same
caution as user input.
• If a third-party API is compromised, insecure consumption can expose the consuming organization to
attack.
• Compromised APIs can serve as vectors to infiltrate otherwise secure systems.
OWASP Attack Vector Description
• Attackers exploit this issue by identifying and potentially compromising third-party services integrated
with the target API.
• This typically involves non-public information, making the attack more complex.
• The exploitable APIs are often not easily accessible or vulnerable without prior access or
reconnaissance.
OWASP Security Weakness Description
• Developers may overly trust external APIs and fail to enforce proper security controls.
• Common oversights include weak transport security, poor authentication/authorization, and lack of
input validation/sanitization.
• Attackers can exploit the trust placed in external services once those services are compromised.
OWASP Impacts Description
• The impact depends on how the target API uses the third-party data.
• Potential consequences include exposure of sensitive data, injection attacks, or denial of service.
Summary
• This issue highlights the need to treat third-party APIs with the same scrutiny as internal or user-facing
APIs.
• Insecure third-party APIs can become a point of compromise that extends to all connected systems.
• Lack of encryption or input validation can allow attackers to intercept or manipulate data.
• Security standards for third-party APIs should match those used for Internet-facing services.
OWASP Preventative Measures
• Assess the security practices of third-party API providers before integration.
• Use TLS for all API communications.
• Sanitize and validate all data received from third-party APIs.
• Implement an allowlist for redirects from third-party APIs and avoid blindly following unknown
redirects.

Injection
Intro
• Injection vulnerabilities have existed for over 20 years and remain a serious threat.
 • These occur when attackers send commands that are executed by the backend systems supporting a
web application.
• Common types: SQL injection, Cross-site Scripting (XSS), OS command injection.
• APIs are another path for injection attacks to reach backend systems.
OWASP 2019 Attack Vector Description
• Attackers send malicious input through injection points (e.g., parameters, inputs, integrated services).
• The input is intended to be processed by an interpreter (e.g., SQL engine, OS shell).
OWASP 2019 Security Weakness Description
• Injection flaws are common in SQL, LDAP, NoSQL queries, OS commands, XML, ORM.
• Easily found in code reviews.
• Attackers use scanners and fuzzers to identify them.
OWASP 2019 Impacts Description
• Can lead to data leakage, data loss, denial of service (DoS), or complete system takeover.
Summary
• Injection occurs when user input is passed unsanitized to backend systems.
• Supporting systems may interpret input as code and execute it.
• SQL, NoSQL, and OS command injections are common types.
• Attackers can test API responses for signs of injection flaws using malformed input.
• Example: sending ' OR 1=0-- as part of a request might generate a SQL error that reveals a flaw.
• Error messages, unusual HTTP responses, or behavior can all serve as indicators.
• Injection is often paired with poor input sanitization and validation.
• Preventing injection requires a proactive, well-tested security approach.
OWASP 2019 Preventative Measures
• Keep data separate from commands and queries.
• Use trusted, maintained libraries for validation.
• Validate, filter, and sanitize all external input.
• Escape special characters per the interpreter’s syntax.
• Use safe, parameterized APIs where possible.
• Limit records returned to reduce potential exposure.
• Filter incoming data strictly, allowing only valid values.
• Define and enforce strict data types and string patterns.

Logging and Monitoring

Intro
• Logging and monitoring are crucial components of API security.
• They enable detection of attacks and unusual activity.
• Without them, API providers lack visibility and may not notice attacks until significant damage has
occurred.
OWASP 2019 Attack Vector Description
• Attackers exploit systems without detection when logging and monitoring are weak or missing.
OWASP 2019 Security Weakness Description
• Insufficient or absent logging makes tracking and responding to suspicious activity extremely difficult.
 • Timely detection and response become nearly impossible.
OWASP 2019 Impacts Description
• Lack of visibility allows attackers extended time to fully compromise systems.
• Delayed response increases the scale and impact of attacks.
Summary
• Logs help detect patterns, misuse, and abuse of APIs.
• Logging creates an audit trail and is important for compliance and forensic analysis.
• Logs must be protected to prevent tampering.
• Monitoring helps detect suspicious behavior in real time.
• Together, logging and monitoring enhance both performance tuning and security response capabilities.
OWASP 2019 Preventative Measures
• Log all failed authentications, denied access, and validation errors.
• Use a structured log format compatible with log management tools.
• Include enough detail to trace malicious actors.
• Treat logs as sensitive data and ensure integrity during storage and transit.
• Continuously monitor the full stack: infrastructure, network, and APIs.
• Use SIEM systems to centralize, manage, and analyze logs.
• Set up custom dashboards and alerts to detect suspicious behavior early and respond quickly.

Business Logic Vulnerabilities

Intro
• Business logic vulnerabilities (BLVs) are weaknesses tied to the unique policies, workflows, and features
of each API provider.
• Exploitation involves attackers abusing expected features or misplaced trust within the application
logic.
• Identifying these flaws is difficult due to the unique and often complex nature of individual business
processes.
Attack Vector Description
• BLVs exploit the normal, intended behavior of an application's processes.
• They often require a deep understanding of the API's data flows and functionality.
• Each vulnerability is specific to a given application—no universal detection method exists.
Security Weakness Description
• Occur when business rules and assumptions aren't properly enforced by technical controls.
• Can stem from weak input validation, missing authorization checks, or incorrect assumptions about
user behavior.
• Often arise when developers fail to consider all ways users could misuse a feature.
Impacts Description
• Range from unauthorized access to full control bypass.
• May allow attackers to manipulate data, skip steps in business workflows, or bypass critical security
mechanisms.
Summary
• Business logic flaws involve the misuse of legitimate application functionality.
 • A feature may be documented with instructions or constraints, but if those aren't technically enforced,
attackers can exploit them.
• Trust is a major concern—over-trusting partners or assuming users won't tamper with requests can
lead to data exposure or control bypass.
• The 2021 Experian API leak is an example where trust in a partner led to exposed user credit data.
• Attackers can intercept and manipulate API requests, such as altering parameters to bypass security
features (e.g., MFA).
Common Examples
• Allowing file uploads with no proper validation or restriction.
• APIs with rules like “Only admins should call this endpoint,” but without enforced access controls.
• API keys or tokens exposed via frontend requests that can be reused or abused.
• Blindly trusting that users won’t tamper with requests made through the frontend application.
Testing Tips
• Study API behavior and documentation to identify assumptions or warnings.
• Look for signs like “Do not use X” or “Only perform Y” — these often reflect weak trust-based policies.
• Test with an adversarial mindset—try breaking assumptions and misusing intended functionality.
• Automated scanners are not effective—manual exploration and understanding of business logic is
required.
Preventative Measures
• Use threat modeling to identify weaknesses during API design.
• Minimize trust relationships between users, components, and systems.
• Train developers on secure coding, business logic risks, and abuse case thinking.
• Encourage external security reviews through bug bounty programs or third-party testing.
• Establish responsible disclosure policies to uncover unknown vulnerabilities.