Web Services/API Security Testing

Facebook - 50 Million Accounts Hacked Through API Vulnerability (2018)

In 2018, attackers exploited a vulnerability in Facebook’s API to steal access tokens for 50 million accounts. Broken access control in “View As” feature + missing rate limiting = massive leak. Fine: $5 billion from FTC.

Without API security testing:

• Authorization vulnerabilities (BOLA/IDOR) = access to others’ data
• Broken authentication = account takeover
• Missing rate limiting = brute force and credential stuffing
• Injection (SQL, NoSQL, command) = database compromise
• Excessive data exposure = sensitive data leak
• Business logic flaws = payment bypass, excessive privileges

OWASP API Security Top 10 + Business Logic

We test APIs like an attacker would - discovering undocumented endpoints, testing authorization, attempting injection, looking for business logic flaws. For each vulnerability - Proof of Concept and remediation steps.

What you get:

• Mapping all endpoints (documented + hidden)
• API documentation analysis (Swagger/OpenAPI if available)
• Authorization tests (BOLA/IDOR - can I see others’ data?)
• Authentication tests (broken auth, weak tokens, session mgmt)
• Injection testing (SQL, NoSQL, command, LDAP, XPath)
• Rate limiting & brute force protection
• Mass assignment & excessive data exposure
• Security misconfiguration (CORS, headers, verbose errors)
• Business logic flaws (price manipulation, privilege escalation)
• GraphQL specific (batching attacks, introspection, depth limits)
• SOAP specific (XXE, WSDL enumeration)
• Detailed report with Proof of Concept
• Remediation recommendations for devs
• Optional retest after implementing fixes

Who Is It For?

This service is for you if:

• You develop APIs for customers or integrators
• You have mobile app or SPA (React/Vue/Angular) - they use APIs
• APIs are public or accessible from internet
• You want to meet auditor/client requirements (security testing)
• You added new endpoints and want to verify they’re secure
• You’re planning launch and want to avoid security scandal

OWASP API Security Top 10 (2023)

What We Test

API1:2023 - Broken Object Level Authorization (BOLA/IDOR)

• Most common API vulnerability
• Example: GET /api/users/123/profile - can I change 123 to 124 and see others’ data?
• Test: Object ID manipulation in URL/body

API2:2023 - Broken Authentication

• Weak password policy
• No rate limiting on login
• Predictable tokens
• JWT misconfiguration (weak secret, no signature verification)

API3:2023 - Broken Object Property Level Authorization

• Mass assignment - adding fields that shouldn’t be there
• Excessive data exposure - API returns more than needed
• Example: POST user with "isAdmin": true field

API4:2023 - Unrestricted Resource Consumption

• No rate limiting = brute force/credential stuffing
• No pagination = DoS through large response
• No timeout = slowloris attacks

API5:2023 - Broken Function Level Authorization

• Vertical privilege escalation (user -> admin)
• Horizontal privilege escalation (user A -> user B)
• Example: changing method from GET to PUT gives admin access

API6:2023 - Unrestricted Access to Sensitive Business Flows

• Business logic flaws
• Example: buying ticket for $0 through price manipulation
• Automated abuse (scalping, inventory hoarding)

API7:2023 - Server Side Request Forgery (SSRF)

• API makes requests to other systems
• Attacker can change target
• Access to internal services (AWS metadata, internal APIs)

API8:2023 - Security Misconfiguration

• Verbose error messages (stack traces)
• Default credentials
• Unnecessary HTTP methods (TRACE, OPTIONS)
• Missing security headers
• CORS misconfiguration

API9:2023 - Improper Inventory Management

• Undocumented endpoints
• Old API versions (v1, v2) without security updates
• Shadow API (APIs security doesn’t know about)

API10:2023 - Unsafe Consumption of APIs

• API consumes data from third-party API
• No validation of external data
• Trust third-party data = injection

Testing Methodology

How We Test APIs

1. Discovery & Reconnaissance

• Passive: web/mobile application analysis (Burp, OWASP ZAP)
• Active: endpoint fuzzing (common paths, old versions)
• Documentation: Swagger/OpenAPI/WSDL analysis
• GraphQL: introspection query (if enabled)

2. Authentication & Session Management

• Registration flaws (weak validation, no email confirm)
• Login: brute force protection, rate limiting
• Password reset: predictable tokens, account takeover
• JWT analysis: algorithm confusion, weak secret, no signature verify
• OAuth: authorization code interception, redirect_uri manipulation

3. Authorization Testing

• BOLA/IDOR: horizontal (user A -> user B) and vertical (user -> admin)
• For each endpoint: can unauthorized user call it?
• Method manipulation: GET -> POST/PUT/DELETE

4. Input Validation

• SQL injection (classic and blind)
• NoSQL injection (MongoDB, etc.)
• Command injection (OS command execution)
• XML External Entity (XXE) for SOAP
• LDAP injection
• XPath injection

5. Business Logic

• Price/quantity manipulation (negative prices, overflow)
• Race conditions (concurrent requests)
• Workflow bypass (skip payment step)
• Privilege escalation via mass assignment

6. Rate Limiting & DoS

• Brute force protection on login/register
• API abuse (unlimited requests)
• Resource exhaustion (large response, complex queries)

7. GraphQL Specific

• Introspection (schema disclosure)
• Batching attacks (multiple queries in one request)
• Depth limit bypass (nested queries -> DoS)
• Field suggestions (typo -> schema leak)

8. Data Exposure

• Sensitive data in response (passwords, tokens, PII)
• Unnecessary fields (internal IDs, debug info)
• Error messages revealing structure

Example Vulnerabilities We’ve Found

Case 1: BOLA in Banking API

Endpoint: GET /api/accounts/{accountId}/transactions Vulnerability: No verification if user has access to accountId Exploit: Changing accountId=12345 to 12346 = access to others’ transactions Impact: Financial data leak for all customers Fix: Backend checks if current user owns accountId

Case 2: Mass Assignment in User Profile

Endpoint: PUT /api/users/{userId}/profile Vulnerability: API accepts any fields in body Exploit: Adding "role": "admin" in request body Impact: Privilege escalation user -> admin Fix: Whitelist allowed fields (name, email, etc.) - rest ignored

Case 3: JWT Algorithm Confusion

Auth: JWT with RS256 algorithm (public key verification) Vulnerability: Backend also accepts HS256 (symmetric key) Exploit: Changing algorithm to HS256 and signing with public key Impact: Forge arbitrary tokens = account takeover Fix: Enforce RS256 algorithm, reject HS256

Case 4: GraphQL Batching DoS

Query: 100x { users { posts { comments { author }}}} in one request Vulnerability: No depth limit and query complexity analysis Exploit: DoS through expensive queries Impact: API down Fix: Implement depth limiting, query complexity cost analysis, rate limiting

Case 5: SSRF Through File Upload

Endpoint: POST /api/upload - file from URL Vulnerability: No URL validation Exploit: "url": "http://169.254.169.254/latest/meta-data/" (AWS metadata) Impact: Access to AWS credentials Fix: Whitelist allowed domains, block private IPs

Related Glossary Terms

Learn more about key concepts related to this service:

• API
• AWS
• DoS
• IDS
• Information Security Architecture
• OT (Operational Technology)
• SCA
• Tor