Common Security Mistakes Developers Often Make—and How to Avoid Them

Engineering Core

ISB Vietnam's skilled software engineers deliver high-quality applications, leveraging their extensive experience in developing financial tools, business management systems, medical technology, and mobile/web platforms.

Security is one of the most critical aspects of software development, yet it often remains an afterthought. In fast-paced "move fast and break things" environments where deadlines are tight and feature delivery takes priority, security vulnerabilities can silently slip into the codebase.

These weaknesses are more than just bugs; they are open doors leading to data breaches, system compromise, financial loss, and catastrophic reputational damage.

In this guide, we explore the top 10 security mistakes developers make, the mechanics behind them, and the actionable best practices to fix them.

Hardcoding Sensitive Information

One of the most frequent and dangerous mistakes is embedding secrets directly into source code. This includes:

API keys
Database connection strings
Encryption keys and salts
Cloud credentials (AWS/Azure/GCP keys)

Developers often do this for quick testing or convenience, but if this code is pushed to a public repository (like GitHub), automated bots will scrape and exploit these credentials within seconds.

How to Fix It

Use Secret Managers: Utilize dedicated services like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault.
Environment Variables: Store sensitive data in .env files (and ensure .env is added to your .gitignore) or environment variables, never in the actual code files.
Automated Scanning: Implement tools like GitGuardian or TruffleHog in your CI/CD pipeline to block commits containing secrets.

Insecure Input Handling (Injection Attacks)

Failing to properly sanitize or validate user input is the root cause of injection attacks.

- SQL Injection (SQLi): Attackers manipulate database queries.
- Command Injection: Executing arbitrary system commands.
- NoSQL Injection: Manipulating document-oriented database queries.

If an application accepts input blindly, attackers can trick the backend into leaking data or granting administrative access.

How to Fix It

Parameterized Queries: Always use prepared statements or parameterized queries. Never concatenate strings to build SQL queries.
Use Modern ORMs: Frameworks like Entity Framework, Hibernate, or Prisma handle sanitization automatically—if used correctly.
Input Validation: Validate all input against a strict allowlist (whitelisting) rather than a denylist. Ensure data conforms to expected types (e.g., ensure an age field is an integer).

Missing or Weak Authentication

Authentication is the gatekeeper of your application. Weak implementation makes it trivial for attackers to break in. Common pitfalls include:

No rate limiting (allowing brute-force attacks).
Permitting weak passwords (e.g., "password123").
Hardcoded administrative credentials.

How to Fix It

MFA is Mandatory: Implement Multi-Factor Authentication (MFA) wherever possible.
Rate Limiting: Use tools like Redis or API Gateways to throttle login attempts and lock accounts after repeated failures.
Identity Providers: Don't roll your own crypto. Use established providers like Auth0, AWS Cognito, or Okta.

Broken Access Control (IDOR)

A system may verify who the user is (authentication) but fail to verify what they are allowed to do (authorization).

A common manifestation is Insecure Direct Object References (IDOR). For example, a user visits /invoice/100, changes the URL to /invoice/101, and sees someone else's invoice because the server didn't check ownership.

How to Fix It

Server-Side Checks: Never rely on the frontend to hide buttons. Validate permissions on every API request on the server.
Principle of Least Privilege (POLP): Users should only have the bare minimum permissions necessary to perform their tasks.
Role-Based Access Control (RBAC): Implement strict roles (Admin, Editor, Viewer) and test boundaries regularly.

Improper Error Handling

Detailed error messages are great for debugging but dangerous in production. Revealing stack traces, database schema details, or library versions gives attackers a blueprint of your system's architecture.

How to Fix It

Generic User Messages: Display "An unexpected error occurred" to the user, rather than "SQL Syntax Error at line 42."
Secure Logging: Log the detailed stack traces internally to a secure monitoring system (like Datadog or ELK Stack), but sanitize logs to ensure no PII (Personally Identifiable Information) or secrets are recorded.

Storing Passwords in Plain Text (or Weak Hashing)

Storing raw passwords is a catastrophic failure. If your database is compromised, every user account is immediately stolen. Even using outdated hashing algorithms like MD5 or SHA-1 is effectively the same as plain text due to modern computing power.

How to Fix It

Strong Hashing: Use adaptive hashing algorithms specifically designed for passwords, such as bcrypt, Argon2, or scrypt.
Salting: Ensure every password hash has a unique, random "salt" to prevent Rainbow Table attacks.
NIST Guidelines: Do not force periodic password rotation (which leads to weak passwords). Instead, check new passwords against lists of known breached passwords (e.g., via the Have I Been Pwned API).

Not Using HTTPS Everywhere

Sending data over unencrypted HTTP exposes users to Man-in-the-middle (MITM) attacks. Attackers can intercept session cookies, login credentials, and personal data.

How to Fix It

HTTPS Everywhere: Enable TLS/SSL for all environments, including development and staging. Services like Let’s Encrypt make this free and easy.
HSTS: specific headers (HTTP Strict Transport Security) to force browsers to interact with your site only using HTTPS.
Secure Cookies: Flag all cookies as Secure (HTTPS only) and HttpOnly (inaccessible to JavaScript).

Misconfigured Cloud Services

The cloud is powerful, but complex. A single toggle can leave a database exposed to the entire internet. Common issues include:

Publicly accessible AWS S3 buckets containing private data.
Open database ports (0.0.0.0/0).
Overly permissive IAM roles (e.g., giving an EC2 instance full Admin access).

How to Fix It

Infrastructure as Code (IaC): Use tools like Terraform or CloudFormation to define infrastructure securely and consistently, preventing "click-ops" errors.
Cloud Security Posture Management (CSPM): Use tools like AWS Trusted Advisor, Prowler, or SonarCloud to automatically scan for misconfigurations.

Using Outdated Libraries and Dependencies

Modern software is built on the backs of open-source libraries. However, Software Supply Chain attacks are on the rise. If you use a library with a known vulnerability, your application inherits that vulnerability.

How to Fix It

SCA Tools: Use Software Composition Analysis tools like Dependabot, Snyk, or OWASP Dependency-Check.
Regular Audits: Automate dependency updates. Do not use "abandonware" libraries that haven't been updated in years.
Lock Files: Use package-lock.json or yarn.lock to ensure consistent versions across environments.

Lack of Security Testing

Many teams rely solely on functional testing ("Does it work?") and skip security testing ("Is it safe?"). Security cannot be something you check only one week before launch.

How to Fix It

Shift Left: Integrate security early in the development lifecycle.
SAST & DAST: Use Static Application Security Testing (analyzing code) and Dynamic Application Security Testing (simulating attacks on the running app).
Penetration Testing: Hire ethical hackers to test your system periodically.

Conclusion

Security isn’t a one-time checkbox—it’s a continuous mindset that must be woven into the fabric of your development culture (DevSecOps).

By understanding these common mistakes and implementing the right tools, you can build software that is not only functional but resilient against attacks.