Authentication and Security

Introduction

An API that works is not the same as an API that is safe. Real services face constant automated attacks, so security is part of the design from the start. This lesson covers the essentials. Treat it as a starting point and follow the current OWASP guidance for anything you put on the internet.

Never store plain passwords

When someone signs up, store a salted hash of the password made with a slow algorithm designed for passwords. Node's built-in crypto module provides scrypt:

Real output:

64
true
false

• The salt is random per user, so equal passwords get different hashes.
• Store the salt and hash (for example as hex text), never the password.
• timingSafeEqual compares without leaking timing information.
• scryptSync blocks the event loop while it works. In a busy server, use the asynchronous scrypt function so other requests are not delayed.
• Many teams prefer a well-reviewed library for Argon2id or bcrypt. Use current recommended settings.

Sessions or tokens?

After logging in, the server needs to recognise the user on later requests.

• Server-side sessions: the server stores the session and gives the browser a random ID in a cookie. Easy to revoke, and a good default for websites. Use HttpOnly, Secure and SameSite cookie flags.
• Tokens (such as JSON Web Tokens): a signed token the client sends with each request, often in an Authorization header. Useful for APIs used by apps and several services, but harder to revoke, so keep them short-lived and verify signature, expiry and audience on every request.

Whichever you choose, use a well-maintained library, keep secrets out of code, and protect login pages from abuse.

A security checklist

1. HTTPS everywhere, terminated by a trusted proxy or platform.
2. Validate all input with schemas, as in the intermediate course.
3. Parameterised database queries only.
4. Security headers using a library such as Helmet, which sets sensible defaults.
5. Rate limiting on login and expensive routes, to slow brute-force and scraping.
6. CORS: allow only the origins that need access, never * for credentialed requests.
7. Limit body sizes and request timeouts.
8. Do not leak errors: log details privately and return generic messages.
9. Authorisation checks on every request: confirm the user may access that resource, not only that they are logged in.
10. Secrets in environment variables or a secrets manager, never in Git.
11. Keep dependencies updated and run npm audit.
12. Least privilege: run as a non-root user with minimal permissions, and give the database account only what it needs.
13. Log security events, such as failed logins, without logging passwords or tokens.

Common mistakes

• Using Math.random() for tokens. Use crypto.randomUUID() or randomBytes.
• Trusting IDs in URLs without checking ownership.
• Returning whole database rows, including password hashes, in JSON.
• Disabling certificate checks "to make it work".
• Committing a .env file.

Try it yourself

Add registration and login to your to-do API: hash passwords with scrypt, store users in SQLite, give each todo an owner, and make every todo route check that the logged-in user owns the item. Add rate limiting to the login route.

Summary

• Store passwords as salted scrypt (or Argon2 or bcrypt) hashes and compare with a timing-safe function.
• Choose sessions or short-lived tokens, and verify authorisation on every request.
• Work through a checklist: HTTPS, validation, parameterised queries, headers, rate limits, safe errors, secrets and updates.