An API is the front door to your business data. Your mobile app, website, admin panel and partner integrations all talk to it, which means a single weak endpoint can expose customer phone numbers, order histories or payment references. Most API breaches do not involve sophisticated hacking - they exploit missing checks that could have been caught with a simple list.
This is that list. It is written for founders and product owners to use with their Node.js development team before launch. You do not need to understand every line of code; you need to get a clear "yes, and here is how" for each item.
Why API security deserves its own checklist
Websites have pages; APIs have endpoints that return raw data. Attackers do not need your app's interface - they can call endpoints directly, change IDs in a request, send thousands of requests a minute or submit unexpected data. The OWASP API Security Top 10, a widely respected industry reference, lists the most common risks, and the top one is consistently broken object-level authorisation: a user changing an order ID in a request and seeing someone else's order.
Section A: Authentication and access
1. Passwords are hashed with a strong algorithm
Passwords must never be stored in plain text or with fast hashes like MD5 or SHA-1. Use bcrypt, scrypt or Argon2.
2. Every endpoint checks authorisation, not just login
Being logged in is not enough. The API must verify that this user is allowed to access this specific record. Ask your team to show how a request for another customer's invoice is rejected.
3. Admin endpoints are separate and strongly protected
Admin and staff functions should require role checks on the server, ideally two-factor authentication, and should not be guessable or reachable by regular user tokens.
4. Tokens and sessions expire and can be revoked
Use secure, HTTP-only cookies for web sessions where possible. If using JWTs, keep access tokens short-lived, use refresh tokens carefully and have a way to revoke them when a user logs out or a phone is lost.
5. OTP and login flows are rate-limited
Login, OTP verification and password reset endpoints are prime targets for brute-force attacks and SMS abuse. Limit attempts per phone number, account and IP address.
Section B: Input and output
6. All input is validated on the server
Every request body, query parameter and header should be validated against a schema using a library such as Zod, Joi or class-validator. Front-end validation is for user convenience only.
7. Database queries are parameterised
Use an ORM or query builder properly, or parameterised queries, so user input is never concatenated into SQL. For MongoDB, guard against operator injection by validating input types.
8. Responses return only what is needed
A common leak: the API returns the full user object, including internal fields, password hashes or other customers' details, and the front end simply hides them. Define exactly which fields each endpoint returns.
9. File uploads are restricted
Limit file types and sizes, scan or re-process uploaded images, store files outside the application folder with random names, and never execute uploaded content.
10. Errors do not reveal internals
Production error messages should be generic for users. Stack traces, database errors and file paths belong in logs, not in API responses.
Section C: Traffic and transport
11. HTTPS everywhere
All traffic must use TLS. Redirect HTTP to HTTPS and enable HSTS for web clients.
12. Rate limiting and request size limits
Apply sensible rate limits on all public endpoints, stricter ones on sensitive actions, and cap request body sizes to prevent abuse.
13. CORS is configured deliberately
Allow only your own domains to call the API from browsers. A wildcard CORS policy combined with cookies is a classic misconfiguration.
14. Security headers are set
Middleware such as Helmet for Express sets sensible HTTP security headers in a few lines.
Section D: Secrets, dependencies and infrastructure
15. Secrets are out of the code
API keys for Razorpay, SMS gateways, WhatsApp Business API and email providers belong in environment variables or a secrets manager - never in the repository, never in the front end. Rotate any key that has ever been committed.
16. Dependencies are audited and updated
Run npm audit or a scanning tool on every build. Remove unused packages. Before adding a new package, check that it is actively maintained and widely used.
17. Node.js runs on a supported LTS version
Older Node.js versions stop receiving security fixes. Production should run an active or maintenance LTS release, updated on a schedule.
18. The server is hardened
The app should run as a non-root user behind a reverse proxy such as Nginx, with a firewall allowing only necessary ports, database access restricted to the application server and automatic security updates for the operating system. Our cloud and DevOps team sets this up as standard.
Section E: Monitoring and data protection
19. Logging and alerts are in place
Log authentication events, permission failures, admin actions and payment webhooks - but never log passwords, OTPs, full card details or tokens. Set alerts for unusual spikes in failed logins or errors.
20. Personal data handling is planned
Under the Digital Personal Data Protection Act, 2023, businesses processing personal data of individuals in India have obligations around consent, purpose limitation, security safeguards and responding to data requests. In practice, your API should support: recording consent, limiting who can access personal data, encrypting sensitive fields, deleting or anonymising data when required, and maintaining backups that are themselves protected. Seek legal advice for your specific obligations.
The checklist in one table
| # | Check | Owner | Status |
|---|---|---|---|
| 1 | Strong password hashing | Back-end lead | |
| 2 | Object-level authorisation on every endpoint | Back-end lead | |
| 3 | Admin endpoints protected, 2FA | Back-end lead | |
| 4 | Session/token expiry and revocation | Back-end lead | |
| 5 | Rate limits on login/OTP/reset | Back-end lead | |
| 6 | Server-side schema validation | Developers | |
| 7 | Parameterised queries | Developers | |
| 8 | Minimal response fields | Developers | |
| 9 | Safe file uploads | Developers | |
| 10 | Generic production errors | Developers | |
| 11 | HTTPS and HSTS | DevOps | |
| 12 | Rate and size limits | DevOps / back end | |
| 13 | Strict CORS | Back-end lead | |
| 14 | Security headers | Developers | |
| 15 | Secrets in env/secret manager | DevOps | |
| 16 | Dependency audits | Developers | |
| 17 | Supported Node.js LTS | DevOps | |
| 18 | Hardened server | DevOps | |
| 19 | Logging and alerts | DevOps | |
| 20 | DPDP-aware data handling | Product owner + back end | |
Copy this table into your project tracker and ask for a status and a short note against each line before launch.
Payment webhooks: a special mention
If your Node.js API receives payment confirmations from Razorpay or another gateway, always verify the webhook signature using the secret provided by the gateway, and confirm the payment status with the gateway's API before marking an order as paid. Never trust a "payment successful" message sent from the user's browser or app alone.
How to run this review if you are not technical
You do not need to read code to make this checklist useful. A simple process works well:
- Share the table with your development lead a week before the planned launch.
- Ask for a written note against each line: done, not applicable (with a reason) or pending (with a date).
- For the most important items - authorisation, secrets, payment webhooks and backups - ask for a short live demonstration rather than a written "yes".
- Do not launch with any authorisation or secrets item marked pending.
- Save the completed checklist; it becomes the starting point for the next review.
After launch: security is a routine, not a phase
- Review this checklist whenever major features are added.
- Apply Node.js and dependency security updates promptly.
- Review access: remove former staff and unused API keys.
- Test backups by actually restoring them.
- Consider an independent security assessment for sensitive applications - our cyber security services can help.
Key takeaways
- Most API breaches exploit missing checks, especially object-level authorisation.
- Validate all input on the server and return only the fields each endpoint needs.
- Rate-limit login and OTP flows, keep secrets out of code and audit dependencies.
- Run Node.js on a supported LTS release on a hardened server.
- Verify payment webhooks and plan DPDP-aware personal data handling.
Want a second pair of eyes on your API before launch? Book a free consultation with our team and we will walk through this checklist with you. Explore our Node JS development and API integration services.
