API Security: What It Is, Best Practices, and the OWASP Top 10

Introduction

Every API you expose is a surface attackers will probe, and roughly 80% of successful API attacks come from authenticated users exploiting missing object-level authorization checks. The difference between a secure endpoint and a breached one usually comes down to whether authorization is properly verified on every request. This guide covers the full OWASP API Security Top 10, the defenses that actually work, and how Browserless applies them to secure browser automation at the API level.

What API security is and why it matters

How APIs work and where security fits in

APIs, or application programming interfaces, allow applications to exchange data over a network using standardized protocols. REST APIs use HTTP methods and JSON, SOAP (Simple Object Access Protocol) uses XML with WS-Security, and GraphQL uses a single endpoint with query-based access.

The common thread is that each API call follows a chain: request, authentication check, authorization check, processing, and response. Each step in that chain is a potential attack vector if left unvalidated.

REST APIs dominate the landscape because they're lightweight and stateless, but that statelessness is exactly what makes them harder to secure. Every single request must carry and verify its own credentials rather than relying on a persistent session. There's no "logged in" state that the server remembers for you.

Unlike traditional web app security, there's no human in the loop. You're protecting machine-to-machine communication across web applications, mobile apps, and internal services where nobody's clicking around in a browser to notice something weird. Automated attacks scale instantly, and a single misconfigured endpoint can leak data before anyone realizes it's exposed.

Why APIs are the top attack target

APIs have become the number one attack vector for web applications, and most modern web applications expose dozens or hundreds of API endpoints that attackers can probe. According to Salt Security's 2026 State of API Security report, the number of unique API attackers grew by 400% in just six months.

The breakdown of what's actually failing is worse. According to the same report, 94% of organizations experienced API security problems in production in the past year, yet most still treat API security as something you bolt on after development rather than validating API calls from the start.

Roughly 80% of API attacks came from users who had proper authentication, meaning the real vulnerability is broken authorization, where authenticated users access data that doesn't belong to them.

Most teams can't produce a full inventory of their live API endpoints, and attackers actively scan for the orphaned ones (see API9 below), which is why API discovery is a prerequisite for any serious effort to protect APIs.

Common API vulnerabilities and the OWASP API Security Top 10

The API threat landscape

Your APIs will face a handful of recurring attack patterns. Understanding these makes the OWASP framework click faster, because any effective API security strategy starts with knowing what you're defending against:

• Broken authentication: Weak or missing authentication methods allow attackers to impersonate legitimate API users through credential stuffing, brute-force attacks, stolen API keys, or default credentials that were never changed.
• Authorization failures: Even properly authenticated users can access unauthorized data on objects or functions they shouldn't access. Broken object-level authorization (BOLA), where authenticated users access records that belong to someone else, is the single most exploited API weakness today.
• Injection attacks: SQL injection, cross-site scripting (XSS), and command injection through unvalidated input in API requests. Attackers send crafted payloads that the backend executes as code instead of treating them as data.
• Excessive data exposure: API responses return entire database objects when the client only needs two fields, silently leaking sensitive data like email addresses, internal IDs, access tokens, or financial records.
• Security misconfiguration: Default settings on API endpoints, verbose error messages that reveal stack traces, missing security headers, overly permissive Cross-Origin Resource Sharing (CORS) policies, and unnecessary HTTP methods left enabled.

OWASP Top 10 at a glance. The OWASP API Security Top 10 is the standard framework for categorizing and prioritizing API threats. OWASP first released it in 2019 and updated it in 2023; it now serves as the foundational reference for API developers and security teams conducting compliance audits. Most API security tools map their findings directly to these categories. For a primer on REST API fundamentals that often come up alongside these threats, see our REST API interview guide.

API1: Broken object-level authorization (BOLA)

Attackers manipulate object identifiers in API requests, changing /api/users/123/orders to /api/users/456/orders to gain access to other users' data. You'd be surprised how many APIs only check "is this user logged in?" without verifying "does this user own this specific record?" That gap is what BOLA exploits.

API2: Broken authentication

A weak authentication method allows attackers to compromise API keys, tokens, or sessions through brute-force attacks, credential stuffing, token theft, or session hijacking. Defend with OAuth 2.0 flows, short-lived JSON web tokens (JWTs) with proper signature verification, and never transmitting credentials over unencrypted channels.

API3: Broken object property-level authorization

This category combines excessive data exposure and mass assignment. API responses include properties the user shouldn't see (such as isAdmin or accountBalance), and API inputs accept properties the user shouldn't set (such as role or discount). Fix this by explicitly whitelisting which fields are returned and which are writable per role.

API4: Unrestricted resource consumption

No rate limiting or resource quotas means attackers can exhaust your servers through repeated API calls, run up your compute bill, or brute-force credentials. Implement per-user and per-IP rate limiting, set maximum request sizes, and cap the number of operations per request.

API5: Broken function-level authorization

Regular users can call admin API endpoints by guessing the URL pattern. An attacker who notices /api/users/ might try /api/admin/users/ or /api/users/export and find it works. If your API doesn't independently verify role permissions on every endpoint, the ones you miss become open doors. The gap widens when admin functionality is added later without revisiting the authorization layer.

API6: Unrestricted access to sensitive business flows

Bots can exploit checkout, signup, password reset, or coupon redemption flows at scale, turning business logic into an attack surface. Unlike injection attacks that target technical flaws, this category targets the logic itself.

A bot that creates 10,000 accounts or buys out limited inventory is using the API exactly as designed, just not as intended. Rate limiting, CAPTCHA, and behavioral detection are the main defenses.

API7: Server-side request forgery (SSRF)

Attackers trick your API into fetching attacker-controlled URLs by passing malicious URLs in request parameters. If your API accepts a URL as input and fetches it server-side, an attacker can point it to internal services, cloud metadata endpoints (like AWS's 169.254.169.254), or other infrastructure that should never be accessible from outside. Validate and whitelist all URLs your API fetches on behalf of users.

API8: Security misconfiguration

Defaults left unchanged, permissions set too broadly, verbose error messages that reveal stack traces, unnecessary HTTP methods left enabled, and CORS policies that allow any origin. Security misconfiguration is the catch-all category for everything you forgot to lock down during deployment, and it's also the easiest to prevent with a proper security checklist and automated configuration scanning in your CI/CD pipeline.

API9: Improper inventory management

Shadow APIs, undocumented endpoints someone built and forgot about, and zombie APIs, deprecated endpoints that are still live, create blind spots your security team can't monitor. Attackers actively scan for these orphaned endpoints because they're often unpatched and running outdated code. If you don't have a complete inventory of every API endpoint in production, you can't secure what you don't know exists.

API10: Unsafe consumption of APIs

Your API is only as secure as the external services it calls. If you consume third-party APIs and trust their responses without validation, a compromised or malicious upstream service can inject bad data into your system. Treat external API responses with the same suspicion you'd apply to user input. Validate schemas, check data types, and set strict timeouts on outbound calls.

If you're running browser automation through an API, these risks hit harder. A BOLA vulnerability in a standard REST API leaks JSON. A browser automation API leaks rendered pages, session cookies, screenshots of authenticated dashboards, and extracted content from protected sites. That data is often more sensitive than raw database records because it's already decrypted, rendered, and ready to use.

API security best practices

Authentication and authorization

If your API handles user data, use OAuth 2.0 for authorization and OpenID Connect for identity verification. API keys work for read-only public data or internal services, but once you're dealing with sensitive data or user-specific operations, you need token-based auth with proper scoping.

Treat authentication and authorization as two separate checks that both must pass on every API request. A valid token verifies identity, but each API request still requires a server-side permission check to confirm that a specific user can access a specific resource. Getting this wrong is how BOLA vulnerabilities happen.

Token management and JWTs

When implementing JSON web tokens (JWTs), keep expiration times short (minutes, not days), scope claims to limit what each token can access, and verify signatures on each request. Never store secrets, passwords, or personally identifiable information (PII) in JWT payloads because they're base64-encoded, not encrypted, so anyone with the token can read the entire payload.

Never hardcode API keys in source code, frontend JavaScript, or version control. Use secrets management tools like HashiCorp Vault, AWS Secrets Manager, or environment variables at a minimum, and rotate keys on a regular schedule. If your organization requires SOC 2 compliance, your key management practices will be audited.

Access control

Apply role-based access control (RBAC) or attribute-based access control (ABAC) to all API calls, enforcing it at both the object level (which records this user can see) and the function level (which endpoints this user can call).

Enforce least privilege everywhere, and verify authorization server-side on every request, not just once at login. The number of APIs that check permissions at the gateway and then trust everything downstream is genuinely alarming.

Encryption and transport security

All API traffic must use Transport Layer Security (TLS) version 1.2 or later. Force HTTPS across all endpoints with no HTTP fallback, use HTTP Strict Transport Security (HSTS) headers to prevent downgrade attacks, and reject connections using any older encryption protocol. If you're storing sensitive data at rest, AES-256 is the standard.

Rate limiting

Set limits per user, per IP, and per endpoint to block brute-force, credential-stuffing, denial-of-service, and automated enumeration attempts. Use exponential backoff for repeated failures and return 429 status codes with Retry-After headers so legitimate clients know when to retry.

Input validation

Client input is untrusted. All of it. Even requests from your own frontend. Validate against a strict JSON Schema, whitelist allowed values and field types, sanitize against SQL injection and XSS, and reject requests that don't match the expected format before they reach your backend. The validation layer is your first line of defense against injection-based API attacks.

API gateways and WAFs

Place your APIs behind an API gateway (AWS API Gateway, Kong, or Apigee) for centralized authentication, rate limiting, request logging, and traffic management. Layer a web application firewall (WAF) on top to filter known attack patterns like injection payloads and malformed requests.

Monitoring and logging

The last layer is visibility. Log API activity in real time and set up alerts for spikes in 4xx/5xx errors, abnormal request volumes from a single user hitting specific API endpoints, unexpected geographic origins, or access to deprecated endpoints. Never log passwords, API keys, tokens, or PII in your logs. Your monitoring system shouldn't become another attack surface.

How Browserless handles API security

The defenses above apply to any API, but browser automation APIs have a unique exposure: every session executes real code in a real browser that touches real websites. If session isolation fails, one customer's cookies, login state, and page data can bleed into the next request. If rate limiting is too loose, a single user can spin up hundreds of browser sessions and use your infrastructure as a launchpad. The browser itself becomes part of the attack surface, which is why the security model must extend beyond the API layer to encompass how sessions are created, isolated, and destroyed.

Token authentication, TLS, and session isolation

Every request to the REST API endpoints requires a valid API token passed as a query parameter (?token=YOUR_API_TOKEN). Invalid tokens get an immediate 401/403 response, and you can manage your tokens from the dashboard.

All connections are encrypted with HTTPS/TLS by default across every regional endpoint, whether you're connecting to US West (production-sfo), Europe UK (production-lon), or Europe Amsterdam (production-ams). There's no option to connect over plain HTTP, and WebSocket connections use wss:// exclusively.

Session isolation is where Browserless puts the most emphasis: each browser session runs in its own isolated environment with a separate user data directory, so one user's browser state, cookies, and page data can never leak into another user's session.

For stateless endpoints like /content, /pdf, and /screenshot, every trace of the session (browser state, cookies, downloaded files, page data, and cached resources) is torn down the moment the response is returned. If you opt in to the Session API, Browserless gives each session its own isolated userDataDir that persists for a TTL you control, then destroys it when the session is closed or expires. See the Session Management docs for the full lifecycle.

Browserless also enforces built-in rate limiting and resource management to protect against API abuse and ensure fair allocation across all API users.

For teams running browser automation at scale, this is critical to maintaining session reliability. If data residency matters to your use case, regional endpoints let you control where your browser sessions run.

All of those security layers are visible in a single /content API call:

# Token auth: invalid tokens get 401, rotate anytime from dashboard
# TLS enforced: this endpoint only accepts HTTPS, no HTTP fallback
# Session isolation: this request gets its own isolated browser environment
# Rate limited: exceeding your plan limits returns 429

curl -X POST \
  "https://production-sfo.browserless.io/content?token=YOUR_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com/",
    "waitForTimeout": 2000
  }'

# Response: fully rendered HTML
# After response: cookies, cache, DOM, browser state all destroyed

Standard API security testing covers your endpoints, but browser automation adds a layer that most scanners won't catch: whether browser state is truly isolated between sessions.

A clean OWASP scan doesn't tell you if a crashed session left cookies on disk or if one customer's browser profile is leaking into the next request. When your API renders authenticated pages on behalf of customers, verifying session isolation is just as important as scanning for injection vulnerabilities.

Conclusion

The gap between secure and insecure APIs is usually implementation, not knowledge. The OWASP API Security Top 10 provides a threat model to prioritize fixes, and the defenses covered in this guide are well understood. The hard part is applying them consistently across every endpoint, every request, and every session. Browserless applies the same model across its REST API: token authentication, HTTPS-only connections, isolated browser sessions, and automatic teardown after every stateless request. Sign up for a free trial and see how it works in practice.

FAQs

What is API security?

Protecting APIs from unauthorized access, data breaches, and abuse. It covers authentication, authorization, encryption, rate limiting, and input validation across every endpoint your application exposes.

What are the most common API security risks?

Broken object-level authorization (BOLA), broken authentication, excessive data exposure, security misconfiguration, and injection attacks. BOLA accounts for roughly 40% of all API attacks because most APIs check whether a user is logged in but not whether they should access that specific resource.

What is the OWASP API Security Top 10?

A standardized list of the most critical API security risks, maintained by OWASP. First released in 2019, updated in 2023. It covers everything from broken authorization to security misconfiguration, and most API security tools map their findings directly to these categories.

How does session isolation affect API security for browser automation?

Browser automation APIs render authenticated pages, retain cookies, and cache session state, which means they leak far more than JSON if sessions are not isolated. A missing isolation layer can let one customer's logged-in state bleed into the next user's session, so each session runs in its own environment with a dedicated userDataDir, and that state is torn down when the session closes.

What is the difference between API authentication and API authorization?

Authentication verifies who is making the request (via API keys, OAuth tokens, or JWTs). Authorization determines what the client can access and is enforced through RBAC or ABAC. Most API breaches exploit authorization failures rather than authentication failures. A user with a valid token accessing another user's data is an authorization problem.