API Security Basics: Don't Expose Your Endpoints

The short version

Your API is your app's nervous system. Every button click, every form submission, every data load hits an API endpoint. If those endpoints aren't properly secured, attackers don't need to find fancy vulnerabilities. They just call your API directly.

The OWASP API Security Top 10 catalogs the most critical API security risks. Let's walk through the ones that matter most for apps built with modern tools.

Your frontend is not a security layer

Here's the thing most vibe coders miss: everything your frontend does, an attacker can do from their terminal with curl. Your frontend is a convenience for users. It's not a gatekeeper.

# An attacker can call your API directly
curl https://yourapp.com/api/users \
  -H "Authorization: Bearer stolen-or-guessed-token"

If your API doesn't validate permissions on every single request, it doesn't matter how pretty your UI is. The data is exposed.

The biggest API security mistakes

1. Broken Object Level Authorization (BOLA)

This is the #1 risk in the OWASP API Security Top 10. It happens when your API uses object IDs that users can manipulate:

GET /api/orders/42       # Your order
GET /api/orders/43       # Someone else's order (works too!)

If the API doesn't check that the authenticated user owns order 43, any user can access any order by changing the ID.

Fix: Always verify that the authenticated user has permission to access the requested resource. Don't trust IDs from the client.

2. Broken Authentication

Weak authentication lets attackers impersonate users. Common issues:

• No rate limiting on login attempts (brute force)
• Tokens that never expire
• Weak token generation (predictable JWTs)
• API keys in URLs (logged by servers, proxies, and browsers)

Fix: Use established auth libraries (Supabase Auth, Auth0, Clerk). Don't roll your own unless you know exactly what you're doing.

3. Excessive Data Exposure

Your API returns more data than the frontend needs. The frontend only shows the user's name, but the API response includes their email, address, and internal IDs.

{
  "name": "Alice",
  "email": "alice@example.com",
  "ssn": "123-45-6789",
  "internal_role": "admin",
  "password_hash": "$2b$10..."
}

The frontend hides the extra fields, but the attacker reads the raw response.

Fix: Only return the fields the client needs. Use explicit field selection instead of SELECT *. Create specific response DTOs.

4. No Rate Limiting

Without rate limits, an attacker can:

• Brute force login credentials
• Scrape all your data
• Run up your cloud bill (if you pay per API call)
• Launch denial-of-service attacks

Fix: Implement rate limiting at the API gateway or middleware level. At minimum, limit login attempts and expensive operations.

5. Missing Input Validation

If your API accepts user input and passes it straight to the database, you're vulnerable to injection attacks, unexpected data types, and oversized payloads.

Fix: Validate every input. Use schema validation libraries (Zod, Joi, Yup). Validate types, lengths, and formats.

Quick checklist

• Every endpoint checks authentication
• Every endpoint checks authorization (not just "is logged in" but "can access THIS resource")
• Responses only include necessary fields
• Rate limiting is in place
• Input is validated and sanitized
• API keys are not in URLs or client-side code
• Error messages don't leak internal details
• HTTPS is enforced

The Supabase and Firebase angle

If you're using Supabase, your API security is largely defined by RLS policies. If you're using Firebase, it's your Security Rules. In both cases, the database is directly exposed to the client, so these rules ARE your API security.

Check your site

Want to know if your site has this issue? Scan it now and find out in 60 seconds.