Basic OWASP-Aligned Web API Security: A Practical Guide

Web APIs have become the backbone of today’s digital applications. From fintech to e-commerce and mobile apps, almost every system relies on APIs to process data, authenticate users, and connect services. However, this also makes APIs a high-value target for attackers.

Who this is for ?

• Developers building or maintaining web APIs (REST/GraphQL) who want clear, actionable security fundamentals.
• Teams who need a practical checklist to reduce common API risks without getting lost in theory.

Why API security matters ?

• APIs expose data and actions. Without proper controls, attackers can access other users’ data, take admin actions, or crash your system.
• Many breaches happen from simple mistakes: missing authorization checks, trusting user input, or misconfigured servers.

Core principles (remember these everywhere)

• Strong authentication: verify who the caller is.
• Authorization everywhere: verify what they are allowed to do, at object level and function level.
• Least privilege: never grant more than needed.
• Validate input and sanitize output: treat input as hostile.
• Protect from abuse: add rate limits and quotas.
• Encrypt in transit: HTTPS only, no exceptions.
• Fail-safe errors: don’t leak internals in error messages.
• Log and monitor: detect anomalies and respond.
• Know your APIs: inventory, versions, dependencies, and retirement plan.

Common API risks and how to fix them (OWASP-aligned)

1) Broken Object Level Authorization (BOLA)

• Risk: User can access another user’s resource by changing an ID in the request.
• Fix: Check ownership/permissions on every resource fetch/update.
• Example: Before returning /orders/{id}, ensure order.userId == req.user.id.

2) Broken Authentication

• Risk: Weak tokens, missing validation, long-lived sessions, predictable resets.
• Fix: Use short-lived JWTs or opaque tokens, validate issuer/audience, rotate secrets, enforce MFA for sensitive actions.
• Example: Reject tokens without exp, iss, aud. Rotate signing keys regularly.

3) Property-Level Authorization

• Risk: User updates fields they shouldn’t (e.g., role) via PATCH/PUT.
• Fix: Enforce a server-side allowlist of updatable fields per role.
• Example: Only accept {name, email}; ignore or reject {role, isAdmin} from user requests.

4) Unrestricted Resource Consumption

• Risk: Attackers overload your API with high-volume or expensive requests.
• Fix: Rate limit, paginate, set timeouts, enforce payload size limits.
• Example: Limit POST /search to 10 requests/minute and response to 50 items/page.

5) Function-Level Authorization

• Risk: Sensitive endpoints (admin/report/export) lack role checks.
• Fix: Check roles/permissions on every action, not just login.
• Example: Require req.user.role == ‘admin’ to access /admin/users.

6) Server-Side Request Forgery (SSRF)

• Risk: API fetches a user-supplied URL and can access internal systems.
• Fix: Validate/allowlist domains, block private IP ranges, disable redirects, use egress filtering.
• Example: Only allow fetching from https://images.example-cdn.com/*.

7) Security Misconfiguration

• Risk: Default headers, verbose errors, open ports, outdated dependencies.
• Fix: Hide server banners, set secure headers, run in production mode, patch regularly.
• Example: Remove X-Powered-By header, return generic “Bad request” without stack traces.

8) Lack of Protection from Automated Threats

• Risk: Credential stuffing, scraping, brute force against login or search.
• Fix: Rate limits, IP/device fingerprints, anomaly detection, CAPTCHA for login extremes.
• Example: Lock account for 15 minutes after 10 failed login attempts.

9) Improper Inventory Management

• Risk: Unknown endpoints, forgotten v1 APIs, outdated docs.
• Fix: Maintain API catalog, version endpoints, deprecate and remove old versions, monitor usage.
• Example: Sunset /v1 by date, block traffic after cutoff, notify clients in advance.

10) Unsafe Consumption of APIs (downstream)

• Risk: Trusting data from third-party APIs without validation; no timeouts/circuit breaker.
• Fix: Validate responses, enforce schemas, set timeouts, retry budgets, and circuit breakers.
• Example: Reject third-party response missing required fields; fallback gracefully on timeout.

Practical checklist you can apply today

• Enforce HTTPS everywhere; HSTS enabled.
• Require authentication for all non-public endpoints.
• Add per-user and per-IP rate limits to login and search.
• Validate IDs against ownership on read/update/delete.
• Only allow specific fields to be updated; ignore extras.
• Return minimal error details; log detailed errors internally.
• Set secure headers: Content-Security-Policy (where applicable), X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Limit request body size and file upload types.
• Maintain an API inventory and versioning policy.
• Monitor logs for anomalies; alert on spikes and auth failures.

Short, concrete examples (language-agnostic patterns)

- Ownership check — If getOrder(id): load order; if order.userId != currentUser.id -> 403 Forbidden.

- Input validation — If createUser: validate email format, password length, reject extra fields not in schema.

- Allowed fields on update — allowedFields = [‘name’, ‘email’] — payload = pick(req.body, allowedFields); ignore others.

- Rate limiting (concept) — Key by userId or IP; allow N requests/minute; exceed -> 429 Too Many Requests.

- Token validation — Verify exp not in past; iss and aud match expected; signature valid; not revoked.

- Secure errors — External response: “Invalid request.” — Internal log: include stack, correlationId, userId, requestId.

Getting started in 30 minutes (quick wins)

• Turn on HTTPS and HSTS; remove server banners.
• Add ownership checks on all “get by ID” and “update/delete by ID” endpoints.
• Implement a basic rate limit on login and search endpoints.
• Enforce an allowlist of editable fields for PATCH/PUT.
• Validate JWTs strictly and reduce token lifetime.
• Add centralized error handling that logs details but only returns generic messages.

How to evaluate your API quickly

• Can a user access another user’s resource by guessing IDs? If yes, fix BOLA.
• Are sensitive endpoints protected by role checks? If not, add authorization.
• Can clients send unexpected fields and change privileged properties? If yes, allowlist fields.
• Do you have rate limits? If not, add them where abuse is likely.
• Do you know every active API version and consumer? If not, build your inventory.

Download Project -Basic-OWASP-Aligned-Web-API-Security

Which contain

• HTTPS redirection and HSTS in production
• Hidden server header; request size limit (1MB)
• Centralized exception handler with safe /error endpoint
• Security headers: X-Content-Type-Options, X-Frame-Options, Referrer-Policy, X-Permitted-Cross-Domain-Policies
• CORS policy reading explicit allowed origins from appsettings.json
• Global rate limiting (100 requests/min per client IP)
• Swagger/OpenAPI with metadata, enabled in all environments
• Minimal sample endpoint (/weatherforecast)

Download Project- Basic-OWASP-Aligned-Web-API-Security

Conclusion

In this article, I aimed to highlight why keeping your API updated is not just good practice, but essential for ongoing security maintenance. By applying basic OWASP-aligned protections, you can defend your system against common external threats and reduce avoidable risks. However, real-world environments continue to evolve, and so do attack methods. For long-term resilience, you’ll need to layer in more advanced security features — ensuring your API stays secure, reliable, and ready to support future growth.

• Authentication and Authorization
• JWT/OIDC authentication, signature and claims validation
• Role/Scope checks and object-level authorization (BOLA protection)
• Input/Output Validation
• Request schema validation and rejecting unknown fields
• Consistent response shaping and safe error contracts
• Abuse and Resource Controls
• Per-endpoint rate limits and pagination
• File upload type checks and antivirus scanning (if applicable)
• Downstream Safety
• SSRF protections and allowlisted outbound domains
• Timeouts, retries, circuit breakers for external calls
• Dependency and Config Hygiene
• Security headers via a reusable middleware extension
• Dependency vulnerability scanning and container image scanning
• Logging/Monitoring
• Structured logging with correlation IDs
• Alerts on auth failures, 4xx/5xx spikes

I offered you others’ Medium articles: Visit My Profile

Also, my GitHub: Md Hasan Monsur

Connect with me at LinkedIn: Md Hasan Monsur