Introduction

API Introduction
What are APIs?
• API stands for Application Programming Interface.
• Often referred to as "websites for machines."
• They enable communication between different services (e.g., Google to Uber, Venmo to Wells Fargo).
• APIs are central to how the internet functions today, used in websites, apps, and systems.
The Perfect API Storm
• 83% of internet traffic is powered by APIs (Akamai).
• API attacks are now the number one attack vector (Gartner).
• Only 4% of organizations prioritize security testing for APIs (RapidAPI); 96% focus on functionality.
Why APIs Are a Prime Target
• APIs connect to sensitive data: personal info, payment data, transaction systems, internal services.
• APIs are easy to find and inspect via browser developer tools.
• They serve as a bridge between the user interface and backend systems.
• Many APIs are over-permissioned and expose logic flaws not visible in the UI.
How API Attacks Happen
• Attackers mimic users: install the app, observe API traffic.
• They bypass the UI and make direct API requests.
• UI is a controlled environment; APIs are open command lines.
• API attacks are simpler and quicker than traditional cyber attacks.
Regulatory and Legal Implications
• T-Mobile breach exposed 37 million records via an API.
• Verizon’s TracFone was fined $16 million and required to follow API security best practices.
• Key regulations addressing API security include:
o PCI DSS 4.0 – covers API-specific risks and developer training.
o GDPR, HIPAA, CCPA – privacy-focused laws impacting API usage.
o SEC – mandates breach reporting and inclusion of API risks.
o UN automotive cybersecurity – relevant for connected cars using APIs.
o FedRAMP – requires monthly security testing, including APIs.
Three Core Regulatory Themes
1. Security – APIs must be securely developed, configured, and maintained.
2. Privacy – APIs accessing sensitive data must meet compliance requirements.
3. Accessibility – Regulations often require APIs for data portability, which must be implemented securely.

OWAPS Top 10
• Part 1: Introduction to OWASP API Security Top 10
o OWASP is a nonprofit that provides top-tier application security guidance.
o In 2019, they released the API-specific Top 10, updated in 2023.
o Real-world breaches show APIs bypass standard defenses (e.g., WAFs, code scanning).
o Common threats: unauthorized access, data exposure, tampering, ransom, etc.
• Part 2: API1 - Broken Object Level Authorization (BOLA)
o Attackers access objects they shouldn't (e.g., User A accessing User B's data).
▪ Examples:
▪ Coinbase: Sold unauthorized Bitcoin due to lack of asset ID validation.
▪ Peloton: API allowed access to 4M users’ data even after "securing" it.
▪ Best Practices:
▪ Design security upfront.
▪ Validate access to each object at the API level.
▪ Don’t rely on the UI for security.
• Part 3: API2 - Broken Authentication
o Missing/weak authentication like no CAPTCHA, 2FA, or using open APIs.
o Example:
▪ Duolingo: 2M+ profiles exposed via API that responded to email queries with detailed
data.
o Best Practices:
▪ Use context-appropriate authentication.
▪ Continuously test and validate authentication mechanisms.
▪ Don’t assume APIs are hidden.
• Part 4: API3 - Broken Object Property Level Authorization (BOPLA)
o Combines Mass Assignment + Excess Data Exposure.
o Example:
▪ Venmo: Public API returned full transaction details (names, not just anonymized data).
o Best Practices:
▪ Enforce data minimization.
▪ Test for excess data and manipulate-able properties.
▪ Define expected fields during design.
• Part 5: API4 - Unrestricted Resource Consumption
o Lack of controls like rate limiting, memory/time constraints.
o Example:
▪ Trello: API abused to send 500M requests, harvesting user info.
o Best Practices:
▪ Implement authentication + rate limits.
▪ Test and simulate volumetric attacks.
▪ Reduce information exposure for unauthenticated users.
• Part 6: API5 - Broken Function Level Authorization
o Users access functions they shouldn’t (e.g., changing account types).
o Example:
▪ Bumble: Users could change their account from free to premium via exposed API.
o Best Practices:
▪ Use Role-Based Access Control (RBAC).
▪ Test permissions across all endpoints.
▪ Limit user access to sensitive functions.
• Part 7: API6 - Unrestricted Access to Sensitive Business Flows
o Focuses on abuse of legitimate business logic.
o Example:
▪ Instagram: Password reset API could be brute-forced due to logic flaws.
o Best Practices:
▪ Avoid predictable patterns (e.g., incremental codes).
▪ Expire reset codes after few tries.
▪ Think like an attacker during design.
• Part 8: API7 - Server-Side Request Forgery (SSRF)
o Tricks server into making unintended requests.
o Example:
▪ Capital One: SSRF exploited WAF misconfig to access internal AWS buckets.
o Best Practices:
▪ Apply least privilege to components.
▪ Validate input URLs.
▪ Simulate SSRF during testing.
• Part 9: API8 - Security Misconfiguration
o Failing to harden servers, set headers, enforce encryption, etc.
o Example:
▪ Experian: API allowed anyone to pull credit data with just a name/address/birthday.
o Best Practices:
▪ Harden infrastructure, review configs.
▪ Use headers like CORS, HSTS.
▪ Regular audits + automated tests.
• Part 10: API9 - Improper Inventory Management
o Lack of visibility and control over APIs (e.g., zombie/shadow APIs).
o Example:
▪ Optus: Unknown public API leaked data on 9.8M users.
o Best Practices:
▪ Define API governance policies.
▪ Use API discovery (traffic, code, crawling, brute-force).
▪ Centralize with API gateways and enforce versioning.
• Part 11: API10 - Unsafe Consumption of APIs
o Risks from integrating third-party APIs without proper vetting.
o Example:
▪ Companies House: Registered a malicious company name that triggered XSS on
viewing.
o Best Practices:
▪ Know and monitor third-party APIs.
▪ Validate and sanitize all inputs.
▪ Ask for pen test results from third parties.
API Attack analysis
Key Insight from API Breach Analysis
• Multiple real-world breaches were analyzed to find common root causes.
• Results showed that just a few patterns are responsible for the majority of incidents.
• A small number of vulnerabilities account for a large portion of risk.
High-Volume Attacks & Rate Limiting
• ~70% of breaches involved some form of high-volume, automated attack (e.g., brute force, scraping).
• These attacks often aim to:
o Harvest large datasets (e.g., millions of user records).
o Exploit misconfigurations or poorly secured endpoints.
Why Rate Limiting Alone Doesn’t Solve It:
• Rate limiting is a mitigation, not a solution.
• It tries to reduce abuse by:
o Limiting requests per user/IP.
o Blocking obvious bot behavior.
How attackers bypass rate limits:
1. Dialing back just below the threshold to avoid triggering alerts.
2. Distributing attacks across thousands of IPs using:
o Residential proxies
o Botnets
3. Blending into normal traffic patterns.
• Your defenses (like WAFs) only have milliseconds to respond, but attackers have months to plan and
execute.
What’s Really Behind the Breaches?
• Beyond rate limiting, core security weaknesses are more important.
• The next three most common issues correspond to OWASP API Top 3.
• These account for 90% of all analyzed breaches.
1. Broken Object Level Authorization (BOLA) – OWASP #1
• Users can access or modify data that belongs to other users.
• Often due to missing or weak authorization checks.
• Real-world examples: Duolingo, Peloton, Trello
o E.g., modifying the user ID in an API request to access someone else’s data.
2. Broken Authentication – OWASP #2
• APIs are exposed without proper identity verification.
• Not about guessing passwords – it’s about no auth at all, or using weak tokens.
• Seen in unsecured APIs or APIs that allow access without verifying users properly.
3. Excessive Data Exposure – OWASP #3
• APIs return more information than necessary.
• Common issue: API response includes sensitive or unnecessary fields (e.g., PII, internal IDs).
• When paired with weak auth or broken authorization, leads to data leaks.
o Example: If you can access your data via API, that's fine. But if the same endpoint allows you to
see someone else's, that's a breach.
Key Takeaways
• Rate limiting is important but not sufficient.
o Think of it as the seatbelt, not the entire crash prevention system.
• Focus on application logic and access controls to prevent deeper vulnerabilities.
• OWASP Top 3 (BOLA, Auth, Data Exposure):
o Addressing these provides maximum security impact.
o They represent the root causes, not just symptoms of breaches.
Training & Organizational Impact
• Security isn’t just the security team’s job.
• Developers must understand API security risks—they’re building the APIs.
• Real-world impact: Devs who attend training often identify vulnerabilities in their own code right
away.
• Promote ongoing education and make security knowledge accessible to engineering teams.

Threat Modeling

Why Threat Modeling?

• Most security frameworks (e.g., NIST 800-53, ISO 27001) begin with threat modeling.
• Purpose: Identify and prioritize risks based on real-world threats, weaknesses, and impacts.
• Helps answer: What are we protecting? From whom? And how?
Core Steps in a Threat Modeling Exercise
1. Define the Attack Surface
• Start with identifying your API footprint:
o Internal and external APIs
o Business functions they enable
o Access methods (public, partner, internal, third-party)
o Mobile apps, websites, microservices, etc.
o Understand how your APIs are used, where they are exposed, and what they connect to.
2. Identify Vulnerabilities
• Look for potential weaknesses in the API ecosystem:
o Logic flaws (business logic gaps, bypasses)
o Broken access controls
o Unsecured third-party APIs or services
o Lack of proper authentication or input validation
o Vulnerabilities can be in design, implementation, or configuration.
3. Assess Likelihood
• Evaluate how likely it is that each vulnerability could be exploited:
o Is the API publicly accessible?
o Is the exploit well-known or easy to find?
o Is it an attractive target?
o Not all vulnerabilities are equally exposed or exploitable.
4. Assess Impact
• Ask: What would happen if this vulnerability were exploited?
o Is it PII, financial data, internal IP, or something else?
o Impact can range from data exposure to financial loss to brand damage.
o A seemingly small flaw could result in massive consequences if it grants access to sensitive
systems.
5. Prioritize Risks
• Use the formula:
Risk = Threat × Vulnerability × Likelihood × Impact
• This helps rank threats based on actual risk, not just severity or fear.
Start with a Key Question: What Do You Have That Attackers Want?
• Identify the assets most attractive to attackers:
o PII / personal data → identity theft, resale on dark web
o Financial data → fraud, theft
o Corporate data / IP → espionage, competitive advantage
o Services & infrastructure → fraud, disruption
o Critical infrastructure → terrorism, activism, mayhem
o Understanding attacker motivation helps anticipate how they might attack.
Understand How Your Business Uses APIs
• APIs are powering websites, apps, micro services — they are everywhere.
• Evaluate:
o Which APIs expose sensitive information or systems?
o Are any APIs public or partner-facing?
o Are APIs used internally between services or externally via integrations?
o Are there third-party APIs you depend on? What data do they access?
o Threats can come from internal misconfigurations as well as external integrations.
Threat Modeling Example: Unknown APIs (Zombie/Rogue APIs)
Threat
• Unknown or undocumented APIs exposed to the internet.
Vulnerability
• These APIs may contain exploitable flaws — poor auth, data exposure, outdated versions.
Likelihood
• Medium to high, depending on attacker reconnaissance capabilities.
• Attackers use scanners and passive analysis to discover forgotten endpoints.
Impact
• Potentially severe — e.g., Optus breach: 10 million subscriber records exposed via an unknown API.
• Unknown api === High risk
Three Pillar of API security

Governance
The Goal of Governance
• Governance aims to establish consistency in how APIs are developed, deployed, tested, and managed.
• It sets clear expectations for engineering teams regarding API creation and publishing.
Key Governance Expectations
• Define documentation requirements, authentication policies, versioning standards, and API
retirement processes.
• Ensure standardized workflows for moving APIs from development to production.
• Enforce security checks before any API is deployed to production.
Two Core Components of Governance
1. Awareness
• Know what APIs you have, why they exist, who owns them, and what functions they perform.
• Understand where they run, what infrastructure they rely on, and what data they access.
• Maintain a comprehensive API inventory.
• Understand the architecture, including containers, VMs, databases, and networks.
• Eliminate shadow or rogue APIs through strong visibility and process enforcement.
2. Policy and Process
• Standardize how APIs are built and deployed.
• Enforce deployment through approved channels only.
• Use API gateways as a central control point to validate APIs before deployment.
• Require complete and up-to-date documentation for all APIs.
Importance of Documentation
• Documentation is essential for both usability and security.
• Use the OpenAPI Specification (OAS) — also known as Swagger — to document APIs.
• Format is typically YAML or JSON, readable by both machines and humans.
• Automate documentation generation where possible.
• Control public and private
• Instrument code repositories to generate specs automatically.
Controlling Access to API Documentation
• Avoid exposing Swagger/OAS files unnecessarily.
• Require registration and validation before granting access to public-facing API documentation.
• Only publish what is absolutely necessary.
What API Documentation Should Include(Define Capabilities)
• API functionality and endpoints
• Base URL, payloads, authentication methods
• Parameters, data types, HTTP methods
• Security requirements
• Error codes and response structures
API Style Guides
• Publish a style guide to define standard practices across your organization.
• Include:
o Authentication and Authorization rules
oNaming conventions (e.g., nouns for URLs, verbs for methods)
o Error message formatting
o Versioning policies
o Language and tone standards
• Avoid exposing technical details in error messages that could aid attackers.
Example from Atlassian
• Atlassian’s API design guide requires basic user authentication for every REST API.
• Authorization is handled at the application level, not the API layer.
• Versioning guidelines explain when new versions are needed and how old ones are handled.

Monitoring

Monitoring is about understanding how your APIs behave and operate in production.
It can be broken down into three main categories:
1. Runtime Protection
• This involves enforcing real-time policies to protect APIs.
• Policies include requiring authentication for endpoints and filtering traffic by geography or IP.
• It helps prevent unauthorized access and mitigate misuse in real-time.
2. Threat Detection
• This focuses on analyzing traffic for fraud, abuse, or distributed attacks.
• It supports incident response by logging traffic for later analysis.
• It helps identify attack patterns and supports timely remediation.
3. Control Validation
• This ensures that security controls at the gateway, firewall, and app are functioning as intended.
• It detects anomalies or failures in enforcement mechanisms.
• It helps confirm that expected protections are actually active in production.
Two Approaches to Runtime Monitoring
Proactive Blocking
• Uses tools like API gateways and web application firewalls.
• Enforces policy in-line by blocking traffic that fails validation.
• Supports controls like rate limiting and IP allow-listing.
Reactive Monitoring
• Uses alerting and log analysis instead of blocking.
• Sends data to SIEMs, log management, or API threat management platforms.
• Helps avoid blocking legitimate traffic when there isn’t enough context to decide in real-time.
API Discovery via Monitoring
• Monitoring traffic helps identify active and undocumented APIs.
• It supports inventory generation and documentation creation.
• It cannot see everything—some APIs run in environments monitoring tools can’t access.
• Comprehensive discovery requires scanning repos, crawling, and collaboration with dev teams.
Core Challenge of Monitoring
• API attacks often look like legitimate requests.
• WAFs can easily block obvious threats (e.g., SQL injections).
• But they struggle with logic-based attacks that appear valid (e.g., authenticated user deleting data they
shouldn’t own).
• These tools can’t always evaluate business logic context in milliseconds.
Why Monitoring Alone Isn’t Enough
• Many breached organizations had WAFs, SIEMs, and bot defenses in place.
• Monitoring is essential but not perfect—attackers can still bypass protections.
• Monitoring should be combined with continuous testing and deeper security validation

Testing

Testing is about proactively identifying security issues in APIs before attackers do.
Most organizations are under-testing their APIs, especially for security.
The Current Testing Gap
• Surveys show only ~4% of organizations perform API security testing.
• Most focus on positive testing — checking if APIs function correctly.
• Very few invest in negative testing — verifying that APIs don’t do what they shouldn’t.
Types of API Security Testing
Security Testing
• Checks for unsecured endpoints and missing authentication
• Detects issues like incremental IDs, injections, and missing input validation
• Identifies common vulnerabilities like XSS, SQLi, and misconfigurations
Data Testing
• Evaluates the type and sensitivity of data being accessed and returned
• Flags overexposed data or excessive responses
• Considers privacy and regulatory concerns
Logic Testing
• Identifies abuse of business logic and broken authorization controls
• Catches BOLA (Broken Object Level Authorization) and cross-user access issues
• Uncovers scenarios like function abuse or object ID tampering that traditional tools miss
The Challenges of API Security Testing
• Coverage is difficult due to the variety and depth of test cases required
• Manual attack simulations are time-consuming and require expertise
• Security testing is often infrequent (e.g., annual pen tests), missing continuous changes
• Integrating testing into development workflows is critical but rarely done
Common Approaches to API Testing
1. Do Nothing
• Often the default due to time, resource, or awareness gaps
• Dangerous assumption that APIs are hidden or secure by design
2. Do It Yourself
• Involves internal teams using tools like Postman, Burp, or OWASP Zap
• Requires deep expertise and time investment
• Hard to scale across large API environments
3. Hire a Pen Tester
• Uses third-party firms for manual testing
• Typically happens once a year, not continuously
• Covers limited APIs and depends heavily on tester skill
The Need for a Better Option
1. Testing must be automated, continuous, and shifted left in the SDLC
2. Integrating into CI/CD allows tests to run with each new build
3. Automated testing tools can simulate thousands of attacks across OWASP categories without requiring
deep expertise
Key Takeaway
Organizations must upgrade from occasional, manual testing to automated and continuous testing to protect
their APIs effectively.

Application Security Technology

This section narrows in even further — on API Security, which has become a critical, often under-protected
layer within application security/
2. Well-Established Application Security Technologies
There’s a mature set of tools that support secure software development:
• SAST (Static Application Security Testing): Analyzes source code for vulnerabilities.
• DAST (Dynamic Application Security Testing): Tests running applications to identify behavioral issues.
• SCA (Software Composition Analysis): Detects vulnerabilities in third-party and open-source
components.
• Container Security: Scans container images and infrastructure for misconfigurations.
• Web Application Firewalls (WAFs): Block common web attack patterns.
• Web Scanners: Tools like Nessus or Burp Suite that check for known vulnerabilities.
These tools are strong at catching known CVEs, but they often miss API-specific risks.
3. The API Security Gap
Despite mature security tools, API breaches are on the rise. This is because APIs expose unique risks:
• Direct access to business logic
• Heavy reliance on proper authorization
• High-volume sensitive data exposure
Most API flaws aren’t traditional CVEs. Instead, they involve:
• Logic flaws
• Broken authorization
• Misconfigured endpoints
• Excessive data access
Standard tools often miss these deeper, API-specific issues.
4. Applying Security Across the API Lifecycle
Security must be implemented across the entire API lifecycle, from design to decommissioning.
Definition
Discuss risks during design. Model threats, define controls, and understand data exposure.
Development
Review code for logic issues. Use SAST and SCA. Prioritize logic-based issues over simple syntax flaws.
Testing
Perform API-specific security testing — manual and automated. Validate authentication, authorization, and rate
limiting.
Deployment
Secure infrastructure using API gateways and apply least privilege.
Runtime
Use WAFs, API gateways, and SIEMs to monitor traffic and block attacks.
Decommissioning
Remove outdated APIs. Clean up unused endpoints and stale tokens.
Security should be shifted left — addressed as early in the lifecycle as possible.
5. Mapping Threats to Lifecycle Mitigations
Examples of threats and where to mitigate them:
• Unknown APIs
o Definition: Inventory all APIs
o Runtime: Discover APIs via WAF or gateway traffic monitoring
• Unauthorized Access
o Development: Implement granular authZ
o Testing: Simulate cross-account access scenarios
• Data Harvesting
o Definition: Define strict data access rules
o Testing: Validate response structures
o Runtime: Rate limit and monitor data access
• Broken Auth Flows
o Development: Use standard auth protocols
o Testing: Validate session handling and tokens
• Deprecated APIs Still Available
o Decommissioning: Track and remove old versions from production

6. Building an API Security Action Plan

• Threat model your APIs to identify and prioritize risks
• Map each risk to the appropriate stage in your API lifecycle
• Mitigate early, test thoroughly, and monitor continuously
• Maintain a prioritized, actionable risk register across your environment

Wrapping Up

Common Sources of API Risk

Based on discussions with hundreds of organizations, these are some of the most common API security
challenges:
1. API Discovery
Many organizations struggle to inventory all their APIs. This is understandable, given how pervasive APIs are.
Even small organizations can have thousands of endpoints. Shadow and rogue APIs are real and must be found
and managed.
2. Vulnerable APIs
APIs serve as pathways to internal data and functionality. Flaws in development, configuration, or coding can
be exploited and lead to breaches.
3. Weak Runtime Defenses
Security teams often focus on production-layer defenses, but there is no silver bullet. Runtime protections are
necessary, but they must be properly implemented and not relied upon as the sole defense.
4. Third-Party APIs
Organizations must track which APIs they use from third parties, how they are used, and ensure they are used
securely.
5. Weak Governance
This reflects the absence of clearly defined policies for API development and operations. Successful
organizations treat APIs as products, complete with dedicated API product managers, ensuring proper oversight.
6. Poor Collaboration
Security and development teams must work together. Fixing an API flaw often requires engineering changes,
not just firewall rules. Strong cross-team collaboration is critical.
APIsec U Top 10 Do’s and Don’ts
1. Don’t trust anything
Assume that user input is malicious until proven otherwise.
2. Do validate all inputs
Ensure all API inputs are sanitized and conform to expectations. Reject anything suspicious.
3. Don’t reveal useful information in error messages
Be helpful, but not specific. Avoid exposing system details that could aid an attacker.
4. Do expect that hackers will find your APIs
Even undocumented endpoints are discoverable. Do not rely on obscurity for security.
5. Don’t have hidden or unadvertised features
All features should be documented and intentional. Hidden endpoints are liabilities.
6. Don’t filter data in the UI
Filtering and access control should be handled in the application layer, not the user interface.
7. Do use an API gateway
Centralize traffic control, management, and enforcement of access policies through an API gateway.
8. Don’t confuse authentication with authorization
Authentication identifies users. Authorization defines what they are allowed to do. Both are essential.
9. Do require API documentation
Keep API documentation comprehensive and up to date. This helps internal teams, external users, and improves
security.
10. Do continuous testing
With every release and every deployment, test for vulnerabilities. Simulate attacks, test for logic flaws and
authorization issues.