Module 9 - Security

API Security

Protecting your APIs from common attacks and misuse.

1The Bank Vault Analogy

Simple Analogy
A bank vault has multiple layers: guards at the door, ID checks, access logs, limited access hours, vault combinations. API security is similar-multiple layers protecting your data. One layer fails? Others still protect you.

Defense in depth: Multiple security layers. Authentication, authorization, input validation, rate limiting, logging-no single point of failure.

2OWASP Top API Vulnerabilities

1

Broken Object Level Authorization (BOLA)

User accesses other users' data by changing IDs

GET /api/orders/123 → GET /api/orders/456 (not your order!)

Fix: Check ownership on every request, not just authentication

2

Broken Authentication

Weak passwords, no MFA, session fixation

Brute force login, stolen tokens

Fix: Strong passwords, MFA, short token lifetimes

3

Excessive Data Exposure

API returns more data than needed

GET /user returns password hash, SSN

Fix: Filter responses. Only return what's needed.

4

Lack of Rate Limiting

No limits on request frequency

Attacker brute forces login 1M times

Fix: Rate limit by IP, user, endpoint

5

Injection

Untrusted data sent to interpreter

SQL injection, NoSQL injection

Fix: Parameterized queries, input validation

3Input Validation

Do
  • ✓Validate on server (not just client)
  • ✓Whitelist allowed values
  • ✓Use parameterized queries
  • ✓Validate data types and lengths
  • ✓Sanitize output (XSS prevention)
Don't
  • ✗Trust client-side validation alone
  • ✗Build SQL with string concatenation
  • ✗Accept any file upload
  • ✗Trust hidden form fields
  • ✗Assume IDs are sequential

4Authentication & Authorization Checklist

✓Use HTTPS everywhere (no exceptions)
✓Implement proper password hashing (bcrypt/Argon2)
✓Add rate limiting to login endpoints
✓Use short-lived access tokens
✓Validate JWT signature, expiration, issuer
✓Check authorization on every request
✓Log all authentication events
✓Implement account lockout after failed attempts

5Security Headers

HeaderPurpose
Strict-Transport-SecurityForce HTTPS (HSTS)
X-Content-Type-OptionsPrevent MIME sniffing
X-Frame-OptionsPrevent clickjacking
Content-Security-PolicyControl resource loading (XSS prevention)
X-XSS-ProtectionBrowser XSS filter (legacy)

6Logging & Monitoring

Log These

  • •Authentication attempts (success/failure)
  • •Authorization failures
  • •Input validation failures
  • •Rate limit hits
  • •Admin actions

Never Log

  • •Passwords (even hashed)
  • •Full credit card numbers
  • •API keys or secrets
  • •Personal data (GDPR)

7Key Takeaways

1BOLA (#1 API vulnerability): always check ownership, not just auth
2Validate inputs on server. Client validation is UX, not security.
3Rate limit everything: login, API calls, password reset
4Set security headers: HSTS, CSP, X-Frame-Options
5Log security events but never log secrets

?Quiz

1. GET /orders/123 works. You try /orders/456. You see someone else's order. Vulnerability?

2. Best way to prevent SQL injection?