5 Common Application Security Vulnerabilities and How to Fix Them

Introduction: The Shifting Battlefield of Application Security

Application security is a dynamic field where yesterday's best practices can become today's vulnerabilities. Having conducted hundreds of security assessments, I've observed a persistent pattern: teams often focus on the latest buzzword threats while leaving foundational doors wide open. The vulnerabilities discussed here are not obscure; they are the workhorses of modern cyber-attacks, responsible for a significant majority of successful data breaches. This article is born from hands-on experience—from reviewing millions of lines of code to responding to real-world incidents. We will not just list vulnerabilities; we will dissect their root causes in modern development contexts, such as microservices, APIs, and cloud-native architectures, and provide nuanced, layered defense strategies that go beyond textbook answers. The goal is to equip you with a practitioner's perspective, blending defensive coding with operational controls.

1. SQL Injection (SQLi): The Persistent Classic

SQL Injection remains alarmingly prevalent, not because it's a new or complex attack, but because it exploits a fundamental trust issue between application logic and data layers. I still find it in applications built with modern frameworks, often introduced through overlooked code paths or misused ORM (Object-Relational Mapping) features.

The Core Vulnerability: Untrusted Data in a Trusted Command

At its heart, SQLi occurs when an application concatenates user input directly into a SQL query string. The classic example is a login form where the backend code builds a query like: "SELECT * FROM users WHERE username = '" + userInput + "' AND password = '" + passInput + "'". If an attacker inputs ' OR '1'='1 as the username, the query's logic is fundamentally broken, potentially granting unauthorized access. However, modern manifestations are subtler. I've seen SQLi in GraphQL resolvers, in ORDER BY clauses, and within table or column names dynamically constructed from user input, which parameterized queries often can't protect.

Beyond Parameterized Queries: A Layered Defense Strategy

While parameterized queries (using prepared statements) are the non-negotiable first line of defense, a robust strategy requires more. First, use an ORM wisely. Tools like Hibernate or Sequelize are not magic bullets. They can still produce injection vulnerabilities if you use their raw query methods with concatenated input (e.g., EntityManager.createNativeQuery("SELECT * FROM table WHERE id = " + userInput)). Always use the ORM's parameter binding. Second, implement strict input validation based on an allow-list (positive) pattern. If a parameter should be a number, validate and cast it to an integer at the application boundary. Third, apply the principle of least privilege to your database accounts. The application's database user should never have DROP TABLE or xp_cmdshell permissions. Finally, leverage runtime protection like Web Application Firewalls (WAFs) with updated SQLi signatures as a compensating control, but never as the primary fix.

Real-World Example and Fix

Vulnerable Code (Node.js with a raw query):
const userId = req.query.id;
const query = `SELECT * FROM orders WHERE user_id = ${userId}`;
db.query(query, (err, result) => { ... });
Fixed Code:
const userId = parseInt(req.query.id, 10); // Validation & type casting
if (isNaN(userId)) { return res.status(400).send('Invalid ID'); }
const query = `SELECT * FROM orders WHERE user_id = ?`;
db.query(query, [userId], (err, result) => { ... }); // Parameterized placeholder
This fix combines validation, type safety, and a parameterized query, creating a multi-layered barrier.

2. Cross-Site Scripting (XSS): The Client-Side Saboteur

XSS allows attackers to inject malicious scripts into content viewed by other users. In the age of single-page applications (SPAs) and rich user-generated content, XSS risks have evolved. I categorize findings into three persistent types: Stored (persistent), Reflected, and the increasingly tricky DOM-based XSS.

Modern XSS Vectors: It's Not Just <script> Tags Anymore

While classic <script>alert(1)</script> injections are often caught, attackers use sophisticated payloads. They exploit HTML attributes (onerror=alert(1)), SVG files containing JavaScript, or misuse of JavaScript frameworks' innerHTML or v-html directives. DOM-based XSS is particularly insidious because the vulnerability is in the client-side code, not the server response. For example, an application using document.location.hash or window.name to update the page without proper sanitization is a prime target.

Comprehensive Mitigation: Encoding, CSP, and Framework Discipline

The mantra "context-aware output encoding" is critical. Data placed into an HTML element needs HTML entity encoding (< for <). Data placed into a JavaScript string needs JavaScript Unicode encoding. Rely on well-audited libraries like DOMPurify for sanitizing complex HTML. The most powerful defense, in my experience, is a strict Content Security Policy (CSP). A header like Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none'; can stop most XSS attacks by preventing the browser from executing unauthorized scripts, even if they are injected. For modern frameworks, always use built-in templating syntax that auto-escapes (e.g., React's JSX, Angular's bindings, Vue's {{ }}) instead of manually manipulating the DOM.

Real-World Example and Fix

Vulnerable Code (React, but dangerously bypassing safety):
function UserBio({ bio }) {
// WARNING: This is dangerously vulnerable!
return <div dangerouslySetInnerHTML={{ __html: bio }} />;
}
Fixed Approach:
1. Sanitize on input/store: Run user `bio` through DOMPurify before saving to the database.
2. Use safe framework patterns: If you must render HTML, use a dedicated sanitized component:
import DOMPurify from 'dompurify';
function SafeHTML({ html }) {
const cleanHTML = DOMPurify.sanitize(html);
return <div dangerouslySetInnerHTML={{ __html: cleanHTML }} />;
}
3. Implement a CSP Header on your server to block any inline scripts as a final safety net.

3. Broken Authentication and Session Management

This broad category covers flaws that allow attackers to compromise passwords, keys, session tokens, or impersonate users. In my assessments, I find these issues are less about cryptographic failures and more about logical flaws and implementation oversights in complex authentication workflows.

Common Pitfalls: Beyond Weak Passwords

Typical vulnerabilities include: session IDs exposed in URLs, sessions that don't timeout (or have extremely long timeouts), session fixation attacks, and insecure "remember me" functionality that uses a predictable token. With the rise of APIs, improper implementation of stateless tokens (like JWTs) is a major issue. For example, storing sensitive data in a client-side-decoded JWT payload, or failing to implement proper token revocation mechanisms.

Building a Robust Authentication System

First, use a battle-tested framework (like Passport.js, Spring Security, or Devise) and don't roll your own crypto. For sessions, ensure they are: 1) Stored server-side (or use signed, encrypted cookies), 2) Have absolute and idle timeouts, and 3) Are invalidated on logout. For APIs using JWTs, keep them short-lived (minutes/hours) and use a refresh token pattern with a secure, server-side refresh token store. Crucially, implement brute-force protection (account lockout or progressive delays) on all login endpoints. Multi-factor authentication (MFA) should be mandatory for administrative access and highly encouraged for all users.

Real-World Example and Fix

Vulnerable Pattern: Insecure JWT Handling
An API issues a JWT with a 30-day expiry and no refresh mechanism. The JWT contains the user's role. An attacker steals the token and can impersonate the user for 30 days with no way to revoke it.
Fixed Pattern: Short-Lived JWTs with Refresh Tokens
1. Login endpoint validates credentials and issues a short-lived JWT (e.g., 15-minute access token) and a long-lived, random, opaque refresh token (stored in a secure, server-side database).
2. The client uses the access token for API calls.
3. When it expires, the client uses the refresh token at a dedicated `/refresh` endpoint to get a new access token.
4. The server validates the refresh token against its store, issues a new access token, and can optionally rotate the refresh token.
5. On logout or suspicion, the server deletes the refresh token, effectively revoking the session immediately. The access token's short lifespan limits the exposure window.

4. Insecure Direct Object References (IDOR) and Broken Access Control

IDOR is a specific type of access control failure where an application exposes a reference to an internal object (like a database key, filename, or UUID) and the user can manipulate it to access another object's data. In practice, I find access control flaws are the most common way horizontal and vertical privilege escalation occurs.

The Ubiquity of the Problem

It often looks like this: a URL /api/invoice/12345. An attacker changes it to /api/invoice/12346 and views someone else's invoice. This isn't limited to URLs; it can be in API parameters, GraphQL IDs, or file download endpoints (/download?file=../../etc/passwd). The root cause is the server failing to verify that the authenticated user is authorized to perform the requested action on the specific resource.

Implementing Proper Authorization Checks

The fix is straightforward in concept but requires discipline: always perform authorization checks at the server. Never rely on hidden fields, client-side checks, or obfuscated IDs. The server must, for every request: 1) Identify the user (authentication), 2) Load the resource the user is trying to access, and 3) Explicitly check if the current user has permission for the requested action on that specific resource. Use a centralized authorization layer or policy engine. For indirect references (like using a filename), use a mapped index or a random, unguessable UUID instead of the direct system name. Implement role-based (RBAC) and/or attribute-based access control (ABAC) models to manage permissions systematically.

Real-World Example and Fix

Vulnerable Endpoint:
// GET /api/users/:userId/profile
app.get('/api/users/:userId/profile', authenticate, (req, res) => {
// Missing authorization check!
const profile = db.getProfile(req.params.userId);
res.json(profile);
});
Fixed Endpoint with Authorization:
app.get('/api/users/:userId/profile', authenticate, (req, res) => {
// 1. Authenticated user is in `req.user`
// 2. Check if the requested userId matches the logged-in user OR if the user is an admin.
if (req.user.id !== parseInt(req.params.userId) && req.user.role !== 'admin') {
return res.status(403).send('Forbidden'); // Enforce authorization
}
const profile = db.getProfile(req.params.userId);
res.json(profile);
});
For more complex scenarios, you would call a dedicated authorization service: if (!authorizationService.canViewProfile(req.user, req.params.userId)) { ... }.

5. Security Misconfiguration: The Death by a Thousand Cuts

This is arguably the most common finding in my engagements. It encompasses default configurations, incomplete setups, verbose error messages, exposed administrative interfaces, and outdated components. In cloud environments, this expands dramatically to include insecure storage buckets, overly permissive IAM roles, and unencrypted data flows.

The Expanding Attack Surface

A security misconfiguration isn't just a default admin password. It's a Docker container running as root, a Kubernetes pod with hostNetwork: true, an AWS S3 bucket set to public, an Azure App Service with detailed error pages enabled in production, or a .git directory exposed on a production web server. It also includes using components (libraries, frameworks) with known vulnerabilities, which tools like OWASP Dependency-Check or Snyk can easily identify.

Building a Secure and Repeatable Configuration Baseline

Security must be part of the deployment pipeline. Adopt Infrastructure as Code (IaC) tools like Terraform or CloudFormation to define your environment, making configurations reviewable, version-controlled, and repeatable. Use hardened, minimal base images for containers (like Alpine Linux). Implement a secure build and deploy pipeline that: 1) Scans dependencies for known vulnerabilities, 2) Hardens application and server configurations (disable unnecessary services, headers, and features), 3) Ensures all communication uses TLS, and 4) Segregates environments (dev, staging, prod). Automate regular scans of your cloud infrastructure for misconfigurations using tools like AWS Config, Azure Security Center, or open-source alternatives. Finally, establish a patch management process for all layers of your stack.

Real-World Example and Fix

Vulnerable Scenario: A development team manually deploys a Node.js app to a cloud VM. They use the default Express.js settings, which leak the X-Powered-By header. Debug mode is left on, exposing stack traces in errors. The server runs under a privileged account, and the database connection uses weak, default credentials.
Fixed Approach via Pipeline & IaC:
1. Infrastructure as Code: Define the VM, network security groups, and a least-privilege IAM role in a Terraform script.
2. Hardened Application Config: Use a configuration management tool (Ansible) or container image to:
app.disable('x-powered-by');
app.set('env', 'production'); // Suppresses detailed errors
// Use environment variables for secrets, never hardcode
3. Pipeline Integration: The CI/CD pipeline runs a dependency scan (e.g., `npm audit`), builds a Docker image from a minimal base, and deploys it to run as a non-root user.
4. Post-Deployment Check: An automated security scan validates the running environment against a hardened baseline.

The Human Element: Cultivating a Security-First Culture

Technical fixes are only half the battle. The most secure code in the world can be undermined by a single social engineering attack or a developer under pressure to bypass a security check. Building a resilient application requires fostering a culture where security is a shared responsibility, not a gatekeeping function performed by a separate team.

Integrating Security into the Development Lifecycle (DevSecOps)

Shift security left. This means integrating security tools and practices early in the Software Development Lifecycle (SDLC). Developers should have access to linters with security rules, IDE plugins that flag vulnerable code patterns, and fast, automated security tests in their local and CI environments. Conduct regular, non-punitive threat modeling sessions for new features. Make security training practical—focus on secure coding workshops for the specific stack your team uses, rather than generic cybersecurity awareness videos.

Promoting Secure Coding as a Craft

Celebrate when a developer finds and fixes a security bug. Include security metrics (like mean time to remediate a vulnerability) in team health dashboards. Encourage peer code reviews with a security checklist. In my experience, when developers understand the "why" behind a security control—the real-world exploit it prevents—they become active participants in the defense, often innovating more elegant and secure solutions than any top-down mandate could produce.

Conclusion: Building Defense in Depth

Addressing these five common vulnerabilities is not about finding a silver bullet. It's about constructing a layered defense—a concept known as defense in depth. No single control is perfect. Parameterized queries can have edge cases, CSP can be bypassed in complex scenarios, and authorization logic can have bugs. The power lies in the combination. By implementing the technical fixes discussed—parameterized queries, output encoding, strict CSP, robust session management, server-side authorization, and automated secure configuration—you create a resilient system where a failure in one layer is caught by another. Remember, application security is a continuous journey of assessment, improvement, and adaptation. Start by ruthlessly hunting for these five vulnerabilities in your own codebase, implement the fixes, and build the processes to ensure they never return. Your users' trust, and your organization's resilience, depend on it.