Modern Web Stacks

Understanding Web Stack Fingerprinting and Framework-Specific Exploitation

Introduction

Modern web applications are rarely built using a single technology. Instead, they consist of multiple components working together, commonly referred to as a web stack.

A web stack typically includes:

• Web server
• Application framework
• Programming language
• Database
• Reverse proxy or CDN
• Authentication middleware
• Client-side framework

Each component leaves behind small clues during normal HTTP communication. These clues allow penetration testers to identify the technologies running behind a website without sending any malicious payloads.

This process is known as stack fingerprinting.

Knowing the technology stack is valuable because vulnerabilities are usually framework-specific. Instead of testing every possible attack, a pentester can narrow the attack surface to known weaknesses affecting the detected software versions.

Learning Objectives

By the end of these notes, you should understand how to:

• Fingerprint modern web stacks using passive HTTP responses
• Recognize common indicators for popular web frameworks
• Understand how middleware works in modern web applications
• Learn the basics of Next.js and Django
• Understand why CVE-2025–29927 affects Next.js middleware
• Understand why CVE-2021–35042 affects Django applications
• Understand why CVE-2021–41773 affects Apache HTTP Server
• Develop a workflow for researching framework-specific vulnerabilities

Understanding the Modern Web Stack

Before looking at vulnerabilities, it helps to understand what actually serves a modern website.

Browser
    │
    ▼
Reverse Proxy / CDN
    │
    ▼
Web Server
(Apache / Nginx)
    │
    ▼
Application Framework
(Django / Next.js / Laravel / Spring)
    │
    ▼
Application Code
    │
    ▼
Database
(PostgreSQL / MySQL / MongoDB)

Each layer has its own responsibilities.

Each component can expose identifying information.

What is Stack Fingerprinting?

Stack fingerprinting is the process of identifying the technologies powering a web application by observing its normal behavior.

Unlike vulnerability scanning, fingerprinting does not require exploit payloads.

Instead, it relies on passive information such as:

• HTTP headers
• Cookies
• HTML source
• URL structure
• Error pages
• Static assets
• JavaScript files
• Default responses

The goal is to answer questions like:

• Is this Apache or Nginx?
• Is the application written in Django?
• Is it using Next.js?
• Which version is running?
• Are there publicly known vulnerabilities affecting this version?

Passive HTTP Signals

1. Response Headers

Headers are often the easiest fingerprint.

Example:

Server: Apache/2.4.49

Immediately tells us:

• Web server is Apache
• Version is 2.4.49

Another example:

X-Powered-By: Express

Likely indicates:

• Node.js
• Express framework

2. Cookies

Frameworks often generate unique session cookies.

Examples:

These cookie names are often enough to identify the backend technology.

3. URL Structure

Frameworks commonly follow predictable routing patterns.

Examples:

/admin/

Often Django.

/wp-admin/

WordPress.

/api/auth

Often Next.js or Express.

4. Error Pages

Frameworks generate distinctive errors.

Examples:

Whitelabel Error Page

Spring Boot.

DisallowedHost

Django.

Next.js Error

Next.js.

5. HTML Source

Hidden clues include:

• Meta generators
• Framework scripts
• Asset paths
• JavaScript bundles

Example:

_next/static/

Immediately suggests Next.js.

What is Next.js?

Next.js is a React framework developed by Vercel.

Instead of being just a frontend library, Next.js allows developers to build full-stack web applications.

It supports:

• Server-side rendering (SSR)
• Static site generation (SSG)
• API routes
• Authentication
• Middleware
• Image optimization
• Routing

A simplified request flow looks like this:

User
   │
   ▼
Middleware
   │
   ▼
Authentication
   │
   ▼
Page

What is Middleware?

Middleware is code that executes before a request reaches the application’s main logic.

It can:

• Verify authentication
• Check permissions
• Redirect users
• Add headers
• Log requests
• Block malicious traffic

Think of middleware as a security guard standing at the entrance.

User
 │
 ▼
Security Guard (Middleware)
 │
 ▼
Application

If middleware is bypassed, protected pages may become accessible.

CVE-2025–29927 — Next.js Middleware Authentication Bypass

Overview

This vulnerability affects certain versions of Next.js that rely on middleware for authentication.

Under specific conditions, attackers can manipulate internal request handling so that middleware is skipped entirely.

As a result:

• Authentication checks never execute.
• Authorization logic is bypassed.
• Protected routes become publicly accessible.

The application itself isn’t vulnerable because of weak passwords or poor session management — the issue is that the security checkpoint is never reached.

Why It Happens

Internally, Next.js uses special headers to track middleware execution.

The vulnerability allowed attackers to abuse this internal mechanism by supplying crafted request headers.

The server mistakenly believed middleware had already processed the request.

Get Salma Fouad’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

As a result:

Normal Request

User
 │
 ▼
Middleware
 │
 ▼
Protected Page

Becomes

Attacker

User
 │
 ▼
Protected Page

The middleware never executes.

Impact

Potential consequences include:

• Authentication bypass
• Authorization bypass
• Access to admin panels
• Exposure of sensitive data

Lessons Learned

Security mechanisms should never rely solely on client-controlled values.

Authentication should also be enforced by backend application logic whenever possible.

What is Django?

Django is a high-level Python web framework.

It follows the Model-View-Template (MVT) architecture.

Browser
   │
   ▼
URL Router
   │
   ▼
View
   │
   ▼
Model
   │
   ▼
Database

Django provides many features out of the box:

• Authentication
• Sessions
• ORM
• CSRF protection
• Admin panel
• URL routing

Because Django is feature-rich, many organizations use it to rapidly develop secure applications.

Common Django Fingerprints

Indicators include:

Headers:

Set-Cookie: sessionid

Cookies:

csrftoken

Admin page:

/admin/

Error pages referencing Django modules.

CVE-2021–35042 — Django SQL Injection

Overview

Certain Django versions contained a SQL injection vulnerability involving the ORM.

The vulnerability occurred when specially crafted input interacted with query construction in specific functions.

Instead of treating input purely as data, parts of the query could be interpreted as SQL.

Why SQL Injection Matters

Applications normally execute queries like:

SELECT * FROM users
WHERE username='alice';

If user input is improperly handled:

SELECT * FROM users
WHERE username=''
OR 1=1;

The database executes unintended commands.

Why Django Was Considered Safe

One reason developers like Django is its ORM.

Instead of writing SQL directly:

User.objects.filter(username="alice")

The ORM safely generates SQL.

However, vulnerabilities can still occur when framework internals improperly construct SQL expressions.

This demonstrates an important lesson:

Framework protections are strong, but they are not infallible.

Potential Impact

Depending on application permissions:

• Read database contents
• Modify records
• Delete information
• Authentication bypass
• Privilege escalation

What is Apache HTTP Server?

Apache is one of the world’s most widely used web servers.

Its responsibilities include:

• Receiving HTTP requests
• Serving web pages
• Executing CGI scripts
• Managing virtual hosts
• Handling modules

Apache functionality is extended through modules.

Examples include:

• mod_ssl
• mod_rewrite
• mod_proxy
• mod_cgi

Apache Fingerprinting

Typical header:

Server: Apache/2.4.49

Immediately reveals both product and version.

CVE-2021–41773 — Apache Path Traversal and RCE

Overview

Apache 2.4.49 introduced a flaw in path normalization.

Attackers could craft specially encoded URLs that escaped the intended document root.

Instead of remaining inside:

/var/www/html

Requests could access files elsewhere on the system.

Example target:

/etc/passwd

What is Path Traversal?

A web server normally restricts access to its web directory.

/var/www/html

Traversal attempts use:

../

to move upward through directories.

Web Root

/var/www/html
      ▲
      │
../
      │
      ▼
/etc/passwd

If traversal protections fail, attackers can read arbitrary files.

Why This Became Remote Code Execution

Reading files alone is serious.

However, if the mod_cgi module was enabled and configured to execute scripts, attackers could go beyond file disclosure.

Instead of simply reading files, they could invoke executable scripts on the server, leading to remote code execution.

This combination made CVE-2021–41773 particularly dangerous.

Impact

Possible consequences include:

• Arbitrary file read
• Credential disclosure
• Source code disclosure
• Remote command execution
• Complete server compromise

A Practical Fingerprinting Workflow

When assessing a web application:

1. Observe HTTP response headers.
2. Inspect cookies for framework-specific names.
3. Review the HTML source for framework artifacts.
4. Examine URL patterns and routing conventions.
5. Trigger harmless error conditions to study error pages.
6. Identify the framework and version.
7. Research known CVEs affecting that specific version.
8. Validate whether the vulnerable feature is actually exposed.
9. Develop a targeted exploitation strategy instead of relying solely on automated scanners.

Key Takeaways

• Modern web applications consist of multiple identifiable components, each contributing to the overall attack surface.
• Passive fingerprinting provides valuable intelligence without requiring exploit attempts.
• Framework-specific indicators such as headers, cookies, error messages, and URL structures help identify the underlying technologies.
• Next.js middleware, Django’s ORM, and Apache’s request processing each illustrate how implementation details can introduce security flaws.
• Understanding how a framework works internally often explains why a vulnerability exists, making exploitation — and mitigation — much easier to understand.
• Effective penetration testing is not about trying every possible payload; it is about identifying the target’s technology stack, researching relevant vulnerabilities, and applying focused testing based on evidence.

Note: This article is inspired by TryHackMe’s Modern Web Stacks Room.

https://tryhackme.com/room/modernwebstacks