API Security Basics

API security starts with a defensive assumption: every request is untrusted. Good security is layered. Authentication, authorization, validation, rate limiting, safe database access, and secret management all cover different failure modes.

Validate Unknown Input

type ParsedProject = { name: string };

function parseProject(input: unknown): ParsedProject {
  if (
    typeof input !== "object" ||
    input === null ||
    typeof (input as { name?: unknown }).name !== "string"
  ) {
    throw new Error("Invalid project payload");
  }

  return { name: (input as { name: string }).name.trim() };
}

Validation should happen before business logic. Treat unknown as the default type at the edge of your system.

Injection and Secrets

Use parameterized queries instead of string interpolation.

await db.query("SELECT * FROM users WHERE email = ?", [email]);

Secrets such as database passwords, signing keys, and API tokens belong in environment-specific secret stores, not committed files.

WARNING

Error responses should help legitimate clients recover without revealing stack traces, SQL text, internal service names, or secret values.

Rate Limiting

Rate limits protect login, password reset, signup, search, and expensive write endpoints. Limits can be per IP, per account, or per token depending on the abuse pattern.

TIP

Security is strongest when boring defaults are automatic. Central middleware for auth, rate limits, and request size limits prevents missed routes.

Further Learning

Search these terms to go deeper:

“OWASP API Security Top 10” — common API vulnerabilities
“SQL injection parameterized queries” — safe database access
“API rate limiting strategies” — preventing abuse
“secret management twelve factor app” — handling credentials by environment

API Security Basics

The golden rule of API security: treat every request as untrusted, even ones from your own app. Good security isn’t one big trick — it’s several small habits layered together.

Always validate what comes in

Never assume the data you receive matches what you expect. Check it before using it:

function parseProject(input) {
  if (typeof input !== 'object' || typeof input.name !== 'string') {
    throw new Error('Invalid project payload')
  }
  return { name: input.name.trim() }
}

Never build SQL by hand-mixing user input

Building a query by pasting user input directly into a string is how SQL injection attacks happen. Instead, always use parameterized queries (placeholders the database fills in safely):

// ✅ safe — the database handles the value safely
await db.query('SELECT * FROM users WHERE email = ?', [email])

Keep secrets out of your code

API keys, database passwords, and signing secrets should live in environment variables (or a secrets manager) — never committed into your source code.

Don’t leak details in error messages

WARNING

Error responses should help the client fix their request, but never leak stack traces, SQL text, or internal details. “Invalid request” is safe; a raw database error message is not.

Rate limit the sensitive stuff

Login, signup, and password reset endpoints are prime targets for abuse. Add a rate limit (e.g. “max 5 attempts per minute”) so attackers can’t hammer them.

In one sentence

Treat every request as untrusted: validate input at the door, use parameterized queries (never string-built SQL), keep secrets out of source code, avoid leaking internal errors, and rate-limit sensitive endpoints like login.

Want to go deeper?

Switch to Expert mode above for the OWASP API Security Top 10 and detailed rate-limiting strategies.