At some point most developers implement JWT, hash passwords with bcrypt, set up OAuth, and mentally tick "security" as done. I understand the logic. Auth is the visible, user-facing part of security. It's what tutorials cover. It's what interviews ask about.
But the vulnerabilities that cause real damage in production? Usually not auth failures. They're the stuff that never made it onto the checklist.
Auth vs authorization: not the same thing
IDOR: Insecure Direct Object Reference is still appearing in codebases built by developers who know better. You authenticate the user at the route level, but you don't check if they're allowed to access that specific resource. So, a user changes ?userId=123 to ?userId=124 in the URL and suddenly they're looking at someone else's data. Every data access point needs its own authorization check. A gate at the route entry isn't enough.
Your dependencies are part of your attack surface
The average Node.js project has hundreds of transitive dependencies. You're not just shipping your code; you're shipping everyone else's code too. Running npm audit occasionally isn't a security practice. You need something in CI/CD that blocks deploys when critical vulnerabilities are found. Snyk, Dependabot, or GitHub's native security alerts can automate most of this without adding meaningful overhead.
Secrets management is not optional
API keys committed to public repos. Production database credentials visible in CI logs. .env files checked into version control. These aren't edge cases, they're regular findings. Use a proper secrets manager: AWS Secrets Manager, HashiCorp Vault, or Doppler. Rotate credentials. Audit access. This is infrastructure-level hygiene and it should be in your dev workflow from day one, not after something goes wrong.
Your error messages are leaking information
Verbose stack traces in production API responses tell attackers your tech stack, your file structure, your database query patterns. Your frontend should receive generic error messages. Your internal logging should receive the details. These should never be the same response. It's a one-line environment check. Do it.
Security isn't something you add at the end of a sprint. It's a default way of thinking about every architectural decision. For teams that want structured support for building secure systems, whether that's audits, implementation, or training, professional cybersecurity services in India work directly with development teams without slowing down the build cycle.
Auth is necessary. It's just not sufficient. Start thinking about what happens after the user gets in.
Top comments (0)