Code Security Vulnerabilities: Complete Guide

Common Code Vulnerabilities

// Vulnerable
const query = "SELECT * FROM users WHERE id = " + userId;

// Secure (parameterized)
const query = "SELECT * FROM users WHERE id = ?";
db.query(query, [userId]);

// Vulnerable
element.innerHTML = userInput;

// Secure (text only)
element.textContent = userInput;

// Secure (with sanitization)
element.innerHTML = DOMPurify.sanitize(userInput);

// Protection with CSRF token
<form method="POST">
  <input type="hidden" name="csrf_token" value="{{csrf_token}}">
  <!-- form fields -->
</form>

// Verify on server
if (request.csrf_token !== session.csrf_token) {
  throw new Error('Invalid CSRF token');
}

// Vulnerable (Python)
data = pickle.loads(user_input)  # Never do this!

// Secure
data = json.loads(user_input)  # Use safe formats
# Validate schema after parsing

// Weak
if (password === storedPassword) { /* OK */ }

// Secure
const match = await bcrypt.compare(password, hashedPassword);

// Session security
app.use(session({
  secret: process.env.SESSION_SECRET,
  cookie: { secure: true, httpOnly: true, sameSite: 'strict' }
}));

// Bad: Sensitive data in logs
console.log(`User ${user.email} with card ${card.number}`);

// Good: Mask sensitive data
console.log(`User ${maskEmail(user.email)}`);

// Good: Encrypt at rest
const encrypted = crypto.encrypt(sensitiveData, key);

How Vulnerabilities Enter Your Codebase

Understanding where vulnerabilities originate is the first step toward eliminating them. Most security flaws are not introduced by careless developers acting alone — they emerge from systemic gaps in how software is designed, built, and maintained. The MITRE CWE Top 25 consistently shows the same weakness classes year after year, which tells us that the industry keeps repeating the same mistakes rather than inventing new ones.

In practice, vulnerabilities enter a codebase through four primary channels. First, hand-written application code introduces injection flaws (CWE-89, CWE-78), broken access control (CWE-862, CWE-863), and memory-safety issues (CWE-787 out-of-bounds write remains the number one weakness in MITRE's rankings). Second, third-party dependencies bring known CVEs into your build — the average modern application pulls in hundreds of transitive packages, and incidents like Log4Shell (CVE-2021-44228) proved that a single logging library can expose an entire organization. Third, infrastructure-as-code and configuration files leak overly permissive IAM policies, public storage buckets, and disabled encryption settings. Fourth, secrets committed to version control — API keys, database passwords, cloud credentials — give attackers direct access without needing to exploit anything at all.

Each channel demands a different detection technique, which is why mature security programs layer SAST, SCA, IaC scanning, and secrets detection rather than relying on a single tool. A SAST engine will never flag a vulnerable version of OpenSSL in your lockfile, and a dependency scanner will never notice a SQL query built by string concatenation in your own code.

The Cost of Late Detection

The economics of vulnerability remediation are heavily front-loaded. Research from NIST and IBM consistently shows that a defect fixed during design or coding costs a fraction of one fixed in production — commonly cited multipliers range from 6x at testing to 30x or more once the flaw ships. Beyond direct engineering time, a production vulnerability carries incident response costs, potential breach notification obligations under GDPR or state privacy laws, and audit findings that can delay SOC 2 or ISO 27001 certifications.

• In the IDE: a vulnerable pattern flagged as the developer types costs seconds to fix — the context is fresh and no review cycle is needed.
• In the pull request: a finding caught by CI scanning costs minutes to hours, but still blocks the flaw before merge.
• In staging: DAST or penetration testing findings require a ticket, triage, prioritization, and a full release cycle to remediate.
• In production: the same flaw may require emergency patching, log forensics to confirm it was not exploited, and customer communication.

Frequently Asked Questions