Secure Coding Practices Every Developer Should Know

Why Secure Coding Matters

Every year, the OWASP Top 10 reminds us that the same classes of vulnerabilities keep appearing in production applications: injection, broken authentication, sensitive data exposure. The root cause is rarely a sophisticated attacker — it is insecure code written by developers who were never taught to think about security.

Secure coding is not a separate discipline. It is a set of habits baked into how you write every line of code. This guide covers the practices that have the highest impact for the least effort.

Validate All Input

Never trust data that comes from outside your system — user forms, API requests, URL parameters, file uploads, webhooks. Every input is a potential attack vector.

Whitelist, do not blacklist

Define what valid input looks like and reject everything else. Blacklisting specific bad patterns (e.g., filtering out <script>) is a losing game because attackers always find new ways around your filters. Instead, validate against a strict schema: expected type, length, format, and allowed characters.

Validate on the server

Client-side validation is a UX feature, not a security control. Attackers bypass your frontend entirely. Every validation rule must be enforced server-side, regardless of what the client does.

// Bad: trusting client input
const userId = req.params.id;
const user = await db.user.findUnique({ where: { id: userId } });

// Good: validate before use
const { id } = validateParams(req.params, { id: z.string().uuid() });
const user = await db.user.findUnique({ where: { id } });

Prevent Injection Attacks

Injection — SQL, NoSQL, command, LDAP — remains the most dangerous class of vulnerability. The fix is simple: never build queries or commands by concatenating user input.

Use parameterized queries

ORMs like Prisma, SQLAlchemy, and ActiveRecord handle this by default. If you write raw SQL, always use parameterized queries or prepared statements.

// Bad: SQL injection vulnerability
const query = `SELECT * FROM users WHERE email = '${email}'`;

// Good: parameterized query
const user = await prisma.user.findUnique({ where: { email } });

Escape output

When rendering user-supplied data in HTML, always escape it to prevent Cross-Site Scripting (XSS). Modern frameworks like React and Next.js escape by default, but be careful with dangerouslySetInnerHTML or template literals that bypass the framework's protection.

Handle Authentication Properly

Hash passwords with bcrypt or argon2

Never store passwords in plain text or with weak hashing algorithms like MD5 or SHA-1. Use bcrypt (cost factor 12+) or argon2id. These algorithms are deliberately slow, making brute-force attacks impractical.

Use short-lived tokens

JWTs should have short expiration times (15 minutes or less). Use refresh tokens stored in httpOnly cookies for session extension. Never store tokens in localStorage — it is accessible to any JavaScript running on the page, including XSS payloads.

Implement rate limiting

Protect login endpoints, password reset, and OTP verification with rate limiting. Without it, attackers can brute-force credentials at thousands of attempts per second.

Manage Secrets Securely

Never commit secrets to Git

Database passwords, API keys, JWT secrets — none of these belong in your codebase. Use environment variables, and manage them with tools like Sealed Secrets (Kubernetes), AWS Secrets Manager, or Vault.

Rotate secrets regularly

Treat secrets like passwords: rotate them periodically and immediately after any suspected compromise. Design your systems so that rotation does not require downtime.

Use .gitignore and pre-commit hooks

Add .env, credentials.json, and similar files to .gitignore. Use tools like git-secrets or detect-secrets as pre-commit hooks to catch accidental commits before they reach the remote.

Secure Your Dependencies

Audit regularly

Run npm audit, pip audit, or cargo audit as part of your CI pipeline. Known vulnerabilities in dependencies are one of the easiest attack vectors because they require zero skill to exploit — the exploit code is often public.

Pin versions

Use lock files (package-lock.json, poetry.lock) and pin major versions. Unpinned dependencies can pull in breaking changes or compromised versions without warning.

Minimize your dependency tree

Every dependency you add is code you did not write and cannot fully audit. Before adding a package, ask: can I write this in 20 lines? If yes, skip the dependency.

Apply the Principle of Least Privilege

Database users

Your application's database user should only have the permissions it needs. A read-only API should use a read-only database connection. Never run your application as a database superuser.

API permissions

Design your authorization model so that every action requires explicit permission. Default to deny. Use granular scopes (e.g., posts:read, posts:write) rather than broad roles where possible.

File system access

Application processes should run with minimal file system permissions. Container images should use non-root users. Writable directories should be limited to what the application actually needs (e.g., /tmp, upload directories).

Log for Security

Log authentication events

Every login attempt (success and failure), password change, and privilege escalation should be logged with timestamps, IP addresses, and user identifiers. This is your audit trail when investigating incidents.

Never log sensitive data

Passwords, tokens, credit card numbers, and personal data must never appear in logs. Sanitize log output and use structured logging so you can control what fields are emitted.

Monitor and alert

Logs are useless if nobody reads them. Set up alerts for anomalies: spikes in failed logins, requests from unusual geolocations, or access patterns that deviate from normal usage.

Conclusion

Secure coding is not about being paranoid — it is about being disciplined. Validate input, parameterize queries, hash passwords properly, manage secrets outside your codebase, audit dependencies, and apply least privilege everywhere. These practices are not difficult, but they require consistency.

Security is not a feature you add at the end. It is a quality of every line of code you write from the start.