Chapter 5: Broken Authentication & Session Management

Welcome back, future security champions! In our previous chapters, we laid the groundwork by understanding the attacker’s mindset and the fundamentals of web security. Now, it’s time to dive into one of the most critical and frequently exploited categories of vulnerabilities: Broken Authentication and Session Management. This is where the bad guys try to impersonate legitimate users or gain unauthorized access, often leading to devastating consequences like data breaches or identity theft.

This chapter will guide you through understanding exactly what “Broken Authentication” means, how attackers exploit weaknesses in login systems and session handling, and most importantly, how to build robust, secure systems that protect your users. We’ll explore the OWASP Top 10 category dedicated to this, demonstrate common vulnerabilities with a simple hands-on example, and then walk through implementing modern, secure practices. Get ready to fortify your applications!

By the end of this chapter, you’ll not only understand the theory but also have practical experience in identifying and preventing these critical security flaws. Let’s make your applications impenetrable!

What is Authentication, Anyway?

Before we talk about broken authentication, let’s nail down what authentication is. At its core, authentication is the process of verifying who a user claims to be. Think of it like showing your ID at a concert: the bouncer checks your ID to confirm you are who you say you are and that you’re old enough to enter.

In web applications, this usually involves:

Username and Password: The most common method. You provide a unique identifier (username/email) and a secret (password).
Multi-Factor Authentication (MFA): Adding an extra layer of security, like a code from your phone or a fingerprint scan, after you’ve entered your password.
OAuth/SSO: Delegating authentication to a trusted third party (like Google or Facebook) or using a single sign-on system across multiple applications.

The goal is simple: ensure that only legitimate, verified users can access their accounts.

Keeping Track: The Magic of Session Management

Once a user is authenticated, the server needs a way to remember them as they navigate through the application. This is where session management comes into play. Imagine you log into an online store. You don’t want to re-enter your username and password every time you click on a product or add something to your cart, right?

The server creates a session for you, which is essentially a temporary, unique identifier (often called a session ID or session token). This session ID is then sent to your browser, usually stored in a cookie. For every subsequent request you make, your browser sends this session ID back to the server. The server then uses this ID to look up your session data and know that it’s still you who’s making the requests.

Here’s a simplified visual of a typical authentication and session flow:

sequenceDiagram participant User participant Browser participant WebApp_Server User->>Browser: Enters Username Password Browser->>WebApp_Server: POST login credentials WebApp_Server->>WebApp_Server: Verifies credentials alt Authentication Successful WebApp_Server->>WebApp_Server: Generates Session ID WebApp_Server-->>Browser: Sets Session Cookie Browser->>User: Redirects to Dashboard User->>Browser: Navigates to profile Browser->>WebApp_Server: GET profile with cookie WebApp_Server->>WebApp_Server: Validates Session ID WebApp_Server-->>Browser: Sends Profile Data else Authentication Failed WebApp_Server-->>Browser: Invalid Credentials Error end

The “Broken” Part: OWASP A07: Identification and Authentication Failures

The OWASP Top 10 (2021) lists A07: Identification and Authentication Failures as a critical risk. This category covers a broad range of vulnerabilities where applications mishandle authentication and session management. Essentially, any flaw that allows an attacker to bypass authentication, assume another user’s identity, or generally compromise session tokens falls under this umbrella.

This category is a consolidation of “Broken Authentication” and “Sensitive Data Exposure” from previous OWASP Top 10 lists, highlighting the pervasive nature and high impact of these issues.

Common ways authentication and session management can break:

Weak Passwords & Brute-Force Attacks:
- Problem: Users choose simple passwords, or applications don’t enforce strong password policies. Lack of rate limiting on login attempts allows attackers to guess passwords repeatedly.
- Attacker Mindset: “Let’s try common passwords, then automated tools to guess millions of combinations.” Or, “Let’s try leaked username/password pairs from other breaches (credential stuffing).”
- Impact: Account takeover.
Insecure Credential Storage:
- Problem: Storing passwords in plain text or using weak, reversible encryption.
- Attacker Mindset: “If I breach the database, I want to get actual passwords, not just hashes.”
- Impact: Full compromise of all user accounts if the database is breached.
Weak Session ID Generation & Management:
- Problem: Session IDs are predictable (e.g., sequential numbers), not long enough, or not cryptographically random. Session IDs are not properly invalidated on logout or password change.
- Attacker Mindset: “Can I guess a valid session ID? Can I reuse an old one?”
- Impact: Session hijacking (attacker takes over an active session).
Session Fixation:
- Problem: An attacker can force a user’s browser to use a specific session ID, then when the user logs in, that session ID becomes valid. The attacker then uses the pre-set session ID to access the user’s account.
- Attacker Mindset: “I’ll give you a session ID, then when you log in, I’ll use that same ID to become you.”
- Impact: Account takeover.
Lack of HttpOnly and Secure Flags for Cookies:
- Problem: Session cookies are accessible via client-side JavaScript (without HttpOnly) or sent over unencrypted HTTP (without Secure).
- Attacker Mindset: “If there’s an XSS vulnerability, I can steal the session cookie. If the site uses HTTP, I can sniff the cookie.”
- Impact: Session hijacking.
Insufficient Logout Mechanisms:
- Problem: Logging out only deletes the cookie from the client’s browser, but the server still considers the session valid.
- Attacker Mindset: “If I stole the session cookie before logout, I can still use it even after the user ’logged out’.”
- Impact: Persistent unauthorized access.

Hands-on Demo: Insecure Session Management

Let’s build a simple Node.js/Express application to demonstrate a common session management flaw and then fix it. This demo will highlight the importance of proper server-side session invalidation.

Prerequisites:

Node.js (LTS version, as of Jan 2026, this would be Node.js 20.x or 21.x. We’ll assume 20.x for stability)
npm (comes with Node.js)

Step 1: Project Setup

First, create a new directory for our project and initialize a Node.js project.

mkdir insecure-auth-demo
cd insecure-auth-demo
npm init -y

Now, install the necessary packages: express for our web server and cookie-parser to easily handle cookies.

npm install express cookie-parser

Step 2: Create the Insecure Server (`server.js`)

Create a file named server.js and add the following code. This server will simulate a very basic, flawed authentication system.

// server.js
const express = require('express');
const cookieParser = require('cookie-parser');
const app = express();
const PORT = 3000;

// In a real app, you'd use a database for users and proper password hashing.
// For this demo, we'll use a hardcoded user.
const USERS = {
    'alice': 'password123',
    'bob': 'securepass'
};

// This is where we'll store active sessions on the server.
// In a real app, this would be a more robust session store (e.g., Redis, database).
const activeSessions = new Map(); // Maps session IDs to usernames

// Middleware to parse JSON bodies and cookies
app.use(express.json());
app.use(cookieParser());

// Simple "home" page
app.get('/', (req, res) => {
    res.send(`
        <h1>Welcome!</h1>
        <p>This is a demo of insecure authentication and session management.</p>
        <p>Try logging in with 'alice' / 'password123'.</p>
        <p>Current session ID: ${req.cookies.sessionId || 'None'}</p>
        <form action="/login" method="POST">
            <input type="text" name="username" placeholder="Username" required><br>
            <input type="password" name="password" placeholder="Password" required><br>
            <button type="submit">Login</button>
        </form>
        <form action="/logout" method="POST">
            <button type="submit">Logout</button>
        </form>
        <br>
        <a href="/dashboard">Go to Dashboard</a>
    `);
});

// Login endpoint (INSECURE version)
app.post('/login', (req, res) => {
    const { username, password } = req.body;

    if (USERS[username] && USERS[username] === password) {
        // Authentication successful!
        // Insecure: Generating a simple, sequential session ID.
        // In a real app, this should be a cryptographically secure random string.
        const sessionId = Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);

        // Store session on the server
        activeSessions.set(sessionId, username);

        // Insecure: Setting cookie without HttpOnly, Secure, and proper expiration.
        // This makes the session ID vulnerable to XSS attacks and interception over HTTP.
        res.cookie('sessionId', sessionId, {
            // maxAge: 3600000, // 1 hour expiration
            // httpOnly: true, // Prevents client-side script access
            // secure: true,   // Only send over HTTPS
            // sameSite: 'Lax' // CSRF protection
        });

        console.log(`User ${username} logged in with session ID: ${sessionId}`);
        return res.redirect('/dashboard');
    }

    res.status(401).send('Invalid credentials');
});

// Logout endpoint (INSECURE version)
app.post('/logout', (req, res) => {
    const sessionId = req.cookies.sessionId;

    // Insecure: Only clearing the client-side cookie.
    // The session is *not* invalidated on the server.
    res.clearCookie('sessionId');

    console.log(`User attempted logout. Session ID ${sessionId} is still active on server.`);
    return res.redirect('/');
});

// Dashboard endpoint (protected)
app.get('/dashboard', (req, res) => {
    const sessionId = req.cookies.sessionId;
    const username = activeSessions.get(sessionId);

    if (username) {
        return res.send(`
            <h1>Welcome to your Dashboard, ${username}!</h1>
            <p>Your secret content is here.</p>
            <p>Your current session ID is: ${sessionId}</p>
            <form action="/logout" method="POST">
                <button type="submit">Logout</button>
            </form>
            <br>
            <a href="/">Home</a>
        `);
    }

    res.status(403).send('Access Denied. Please login.');
});

app.listen(PORT, () => {
    console.log(`Insecure demo server running on http://localhost:${PORT}`);
});

Explanation of the Insecure Code:

sessionId Generation: Math.random().toString(...) is not cryptographically secure. While it generates a random-looking string, it’s not suitable for security purposes.
Cookie Flags: The res.cookie line intentionally omits httpOnly: true, secure: true, and sameSite: 'Lax'.
- httpOnly prevents JavaScript from accessing the cookie, protecting against XSS-based session hijacking.
- secure ensures the cookie is only sent over HTTPS, preventing interception on unencrypted networks.
- sameSite helps mitigate CSRF attacks (which we’ll cover in a later chapter).
Logout Mechanism: When a user logs out, the server only tells the browser to delete its cookie (res.clearCookie). However, the activeSessions Map on the server still contains that sessionId and its associated username. This is the core vulnerability we’ll exploit.

Step 3: Run and Exploit

Start the server:
```
node server.js
```
You should see Insecure demo server running on http://localhost:3000.
Open your browser and navigate to http://localhost:3000.
Login: Enter alice as username and password123 as password. Click “Login”. You’ll be redirected to the dashboard. Observe the session ID displayed.
Simulate Session Stealing:
- Open your browser’s developer tools (usually F12).
- Go to the “Application” tab (or “Storage” -> “Cookies”).
- Find http://localhost:3000 and locate the sessionId cookie.
- Copy the value of this sessionId cookie. This simulates an attacker stealing your session ID (e.g., via an XSS attack or network sniffing if HTTPS wasn’t used).
Logout: Go back to http://localhost:3000 and click the “Logout” button. You’ll be redirected to the home page. Your browser no longer has the sessionId cookie.
Exploitation:
- Crucially, the server still thinks that copied session ID is valid for ‘alice’ because we didn’t invalidate it server-side.
- To prove this, we’ll manually add the stolen session ID back to our browser’s cookies.
- In your browser’s developer tools, go back to “Application” -> “Cookies”.
- Right-click on http://localhost:3000 and select “Add cookie” (or similar option depending on your browser).
- Set Name to sessionId and Value to the session ID you copied earlier.
- Ensure Domain is localhost and Path is /. Leave other fields as default for now.
- Now, without logging in again, try to navigate to http://localhost:3000/dashboard.

What happened? Even though you “logged out,” you were able to access Alice’s dashboard again just by re-injecting the stolen session ID! This is a classic example of a broken logout mechanism and a form of session hijacking. The server never invalidated the session, making the old, stolen session ID still usable.

Step-by-Step Fix: Secure Session Management

Now, let’s fix these issues one by one. We’ll use the express-session library, which provides much more robust session management capabilities.

Step 1: Install `express-session`

npm install express-session

Step 2: Update `server.js` for Secure Sessions

We’ll replace our manual session handling with express-session.

// server.js (SECURE version)
const express = require('express');
const cookieParser = require('cookie-parser'); // Still useful for general cookie parsing if needed
const session = require('express-session'); // NEW: Import express-session
const crypto = require('crypto'); // NEW: For generating cryptographically secure session secret
const app = express();
const PORT = 3000;

// In a real app, you'd use a database for users and proper password hashing.
const USERS = {
    'alice': 'password123',
    'bob': 'securepass'
};

// Middleware to parse JSON bodies
app.use(express.json());

// ----------------------------------------------------------------------
// NEW: Configure express-session
// We need a cryptographically secure secret for session signing.
// For production, this should be loaded from environment variables.
const SESSION_SECRET = process.env.SESSION_SECRET || crypto.randomBytes(32).toString('hex');
console.log("Session Secret (for demo, USE ENV VARS IN PRODUCTION):", SESSION_SECRET);

app.use(session({
    secret: SESSION_SECRET, // A strong secret for signing the session ID cookie.
    resave: false,          // Don't save session if unmodified.
    saveUninitialized: false, // Don't create session until something stored.
    name: 'appSessionId',   // Custom name for the session ID cookie (default is 'connect.sid')
    cookie: {
        httpOnly: true,     // CRITICAL: Prevents client-side JS access to the cookie.
        secure: process.env.NODE_ENV === 'production', // CRITICAL: Only send over HTTPS in production.
        maxAge: 1000 * 60 * 60 * 24, // 24 hours expiration.
        sameSite: 'Lax'     // Recommended for CSRF protection.
    }
}));
// ----------------------------------------------------------------------

// Middleware to check if user is authenticated
function isAuthenticated(req, res, next) {
    if (req.session && req.session.username) {
        return next(); // User is authenticated, proceed
    }
    res.status(403).send('Access Denied. Please login.');
}

// Simple "home" page
app.get('/', (req, res) => {
    res.send(`
        <h1>Welcome!</h1>
        <p>This is a demo of SECURE authentication and session management.</p>
        <p>Try logging in with 'alice' / 'password123'.</p>
        <p>Current username: ${req.session.username || 'None'}</p>
        <form action="/login" method="POST">
            <input type="text" name="username" placeholder="Username" required><br>
            <input type="password" name="password" placeholder="Password" required><br>
            <button type="submit">Login</button>
        </form>
        <form action="/logout" method="POST">
            <button type="submit">Logout</button>
        </form>
        <br>
        <a href="/dashboard">Go to Dashboard</a>
    `);
});

// Login endpoint (SECURE version)
app.post('/login', (req, res) => {
    const { username, password } = req.body;

    if (USERS[username] && USERS[username] === password) {
        // Authentication successful!
        // express-session automatically generates a secure session ID and sets the cookie.
        req.session.username = username; // Store user data in the session object

        console.log(`User ${username} logged in. Session ID: ${req.session.id}`);
        return res.redirect('/dashboard');
    }

    res.status(401).send('Invalid credentials');
});

// Logout endpoint (SECURE version)
app.post('/logout', (req, res) => {
    const username = req.session.username;
    // CRITICAL: Destroy the session on the server side.
    req.session.destroy(err => {
        if (err) {
            console.error("Error destroying session:", err);
            return res.status(500).send('Could not log out.');
        }
        res.clearCookie('appSessionId'); // Clear the session cookie from the client
        console.log(`User ${username} logged out. Session destroyed.`);
        res.redirect('/');
    });
});

// Dashboard endpoint (protected)
app.get('/dashboard', isAuthenticated, (req, res) => {
    // If we reach here, isAuthenticated middleware has confirmed req.session.username exists
    return res.send(`
        <h1>Welcome to your Dashboard, ${req.session.username}!</h1>
        <p>Your secret content is here.</p>
        <p>Your current server-side session ID is: ${req.session.id}</p>
        <form action="/logout" method="POST">
            <button type="submit">Logout</button>
        </form>
        <br>
        <a href="/">Home</a>
    `);
});

app.listen(PORT, () => {
    console.log(`Secure demo server running on http://localhost:${PORT}`);
});

Key Changes and Explanations:

express-session: We’re now using this robust middleware.
SESSION_SECRET: This is a cryptographically secure random string used to sign the session ID cookie. This prevents tampering with the cookie on the client side. In a real application, NEVER hardcode this; load it from environment variables!
Session Configuration:
- secret: The secret string.
- resave: false, saveUninitialized: false: Recommended defaults to prevent unnecessary session creation and saving.
- name: 'appSessionId': Gives our session cookie a custom, less generic name.
- cookie: { httpOnly: true, secure: ..., maxAge: ..., sameSite: 'Lax' }: These are the critical security flags:
  - httpOnly: true: This is paramount. It tells the browser that this cookie should not be accessible via client-side JavaScript (document.cookie). This prevents XSS attacks from stealing your session ID.
  - secure: process.env.NODE_ENV === 'production': This ensures the cookie is only sent over HTTPS. In development (NODE_ENV is not ‘production’), we keep it false for local testing. Always true in production!
  - maxAge: Sets an expiration for the cookie.
  - sameSite: 'Lax': Provides a good balance of security and usability for CSRF protection.
req.session.username: express-session attaches a session object to the request. You can store any user-specific data here, and it’s automatically managed by the session middleware.
req.session.destroy() on Logout: This is the most crucial fix for our demo’s vulnerability. When a user logs out, req.session.destroy() removes the session data from the server’s session store. This invalidates the session ID, making any stolen or old session ID useless. We also res.clearCookie() to remove the cookie from the client’s browser.
isAuthenticated Middleware: A simple middleware to protect routes, ensuring only authenticated users can access them.

Step 3: Test the Secure Version

Stop the old insecure server (Ctrl+C in your terminal).
Start the new secure server:
```
node server.js
```
You should see the session secret printed and Secure demo server running on http://localhost:3000.
Open your browser and navigate to http://localhost:3000.
Login: Enter alice / password123. Click “Login”. You’ll be redirected to the dashboard. Notice you can no longer easily see the session ID in document.cookie if you try to access it via browser console (due to HttpOnly). In the “Application” tab -> “Cookies”, you’ll see appSessionId (our custom name).
Attempt Session Stealing (and fail):
- Copy the appSessionId cookie value from the “Application” tab.
- Click “Logout”.
- Now, try to manually add the stolen appSessionId cookie back into your browser’s cookies, just like you did before.
- Try to navigate to http://localhost:3000/dashboard.

What happened now? You should be denied access! The server, upon receiving the “stolen” session ID, will find that it’s no longer valid in its session store (because req.session.destroy() was called). This demonstrates effective server-side session invalidation.

Mini-Challenge: Implement Basic Rate Limiting

A common attack against authentication is brute-forcing login attempts. Let’s add a simple, in-memory rate limiter to our secure server to prevent too many failed login attempts from a single IP address within a short period.

Challenge: Modify the server.js (secure version) to implement a basic rate-limiting mechanism for the /login endpoint. If an IP address makes more than 5 failed login attempts within a 1-minute window, block further login attempts from that IP for 5 minutes.

Hint: You can use a Map object (e.g., failedAttempts) to store failed attempt counts and timestamps per IP address. Remember to clear old attempts.

What to observe/learn:

How to track and respond to suspicious activity.
The importance of protecting against automated attacks like brute force.
The trade-off between security and user experience (e.g., locking out legitimate users who forget their password many times).

// Example structure for the Map to get you started:
// const failedAttempts = new Map(); // IP -> { count: number, lastAttempt: Date, lockoutUntil: Date }

Common Pitfalls & Troubleshooting

Not Invalidating Sessions on Logout/Password Change: As demonstrated, this is a major vulnerability. Always call req.session.destroy() (or equivalent) on the server side.
Weak Session IDs: Using simple, sequential, or non-cryptographically random strings for session IDs. Always rely on robust libraries like express-session that handle this securely.
Missing HttpOnly and Secure Flags: Forgetting these flags makes your session cookies vulnerable to XSS (HttpOnly) and network sniffing (Secure, if not using HTTPS). Always set httpOnly: true and secure: true (in production).
Lack of Rate Limiting: No protection against brute-force or credential stuffing attacks. Implement rate limiting on login attempts.
Storing Sensitive Data Directly in Session: While express-session is secure, avoid storing highly sensitive, unencrypted data directly in the session store. If you must, ensure it’s encrypted.
Session Fixation Vulnerability: Ensure that a new session ID is generated upon successful authentication. express-session handles this by default, but be aware if building custom solutions.
Long Session Expiration: While maxAge is useful, consider using shorter session durations for higher-risk applications and implementing inactivity timeouts.

Summary

Phew! You’ve just tackled one of the most critical areas in web security. Let’s recap what you’ve learned:

Authentication verifies user identity, and Session Management maintains that identity across requests.
OWASP A07: Identification and Authentication Failures encompasses a wide range of vulnerabilities related to improper implementation of these processes.
Common vulnerabilities include weak passwords, insecure session ID generation, missing cookie flags (HttpOnly, Secure), insufficient logout, and lack of brute-force protection.
You built a demo application to reproduce an insecure logout scenario where a stolen session ID could be reused.
You then fixed the vulnerability by implementing express-session with secure defaults, including server-side session invalidation (req.session.destroy()) and critical cookie flags.
You were challenged to implement basic rate limiting to prevent brute-force attacks.

Understanding and correctly implementing secure authentication and session management is foundational to building trustworthy web applications. Always remember to use robust, well-vetted libraries, configure them securely, and invalidate sessions properly.

What’s Next? Now that your users can log in and out securely, it’s time to protect the data they interact with. In the next chapter, we’ll dive into another notorious OWASP Top 10 category: Injection Flaws, focusing on how attackers sneak malicious commands into your application through input fields. Get ready to learn about SQL Injection, XSS, and more!

References

OWASP Top 10 (2021): The official list of the most critical web application security risks.
- https://owasp.org/www-project-top-ten/
OWASP Cheat Sheet Series - Session Management Cheat Sheet: Detailed guidance on secure session management.
- https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
MDN Web Docs - Set-Cookie header: Comprehensive information on HTTP cookies and their attributes.
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
Express.js - res.cookie() documentation: Official documentation for setting cookies in Express.
- https://expressjs.com/en/api.html#res.cookie
Express-session GitHub Repository: The official repository for the express-session middleware.
- https://github.com/expressjs/session

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.