HTTP fingerprinting is an invaluable way to discover the underlying technologies powering a web application.

From analysing HTTP headers to performing malformed HTTP requests, these reconnaissance techniques help offensive security professionals pinpoint a target’s hidden weaknesses.

The upshot: more targeted attacks and an increased likelihood of uncovering vulnerabilities – as well as lucrative Bug Bounty rewards.

In this article, we’ll explore how HTTP fingerprinting reveals hidden components that may be vulnerable due to misconfigurations or outdated software. Vulnerabilities, especially those related to Common Vulnerability Enumeration (CVE) records, can be overlooked without robust fingerprinting – making this an essential skill for bug bounty hunters and security researchers.

Banner-grabbing and reverse proxy identification

Inferring server banner based on header order

Identifying default file and directory structures

Passive fingerprinting via third-party services

Conclusion: a more targeted approach to bug hunting

HTTP fingerprinting is a recon technique for gathering information about HTTP servers and their related components, such as programming languages, frameworks, proxies, content delivery networks (CDN) and web application firewalls (WAFs). Armed with this information, security researchers can learn how a target’s infrastructure is configured, which in turn sheds light on potential weaknesses.

Understanding the underlying technology stack often gives a direct path to known vulnerabilities or misconfigurations, since each technology comes with its own security history. By ascertaining which software version is in use, you can identify any related CVEs or vulnerability to publicly available exploits.

HTTP fingerprinting involves analysing different aspects of HTTP traffic to pinpoint unique attributes. Many technologies leave unique ‘fingerprints’ – such as special headers or default error pages – which can reveal clues about the environment. Knowing how to interpret these signs enables you to make your attack strategy more targeted and discover flaws more rapidly.

You can learn a lot about a target’s technologies by analysing the HTTP response headers. Common headers that typically expose server or proxy details include 

. Many technologies also use their own custom headers that expose the same details. For instance, with a header structure like 

, you can easily collect these types of headers using extensions or custom-written 

. This type of HTTP header analysis is invaluable, because even a single header can reveal a misconfiguration or an outdated and potentially exploitable software version.

, where servers are induced into revealing information about software banners, provides direct evidence of installed software and its version numbers – which helps security researchers assess which known vulnerabilities might be present in an environment. To grab the banner of a web server or reverse proxy, you can send a HTTP 

 request to the web server and then analyse the HTTP response.

Here are some HTTP responses generated by real Bug Bounty targets that expose their reverse proxy banner:

In these scenarios, detecting the version of the reverse proxy being used for a specific web server was easy.

But what if this fingerprinting method fails to explicitly expose these details? Fortunately, subtle implementation details can give you additional clues about the proxy’s identity.

It might be possible to make an educated guess at the reverse proxy banner based on what order the HTTP response headers are presented in, although this depends on the proxy using default configurations.

Look again at the HTTP response examples given above – can you discern a pattern based on the order of the headers?

If we look closely, we can see that Apache responses put the 

As for the Nginx responses, we can see that the 

 the server header. Nginx is less likely than the Apache reverse proxy to maintain a strict header order, but often follows the header order: 

Armed with this knowledge, we might be able to infer which reverse proxy is being used by a particular web server based on the response below – any ideas which one it could be?

However, since header order can be also affected by different configurations, software versions or security mechanisms that obscure server information, inferring banners based on header order should be combined with other fingerprinting techniques to obtain a clear picture.

We can also fingerprint a server’s proxy or web server by analysing its default error pages. These are revealed when you trigger HTTP status codes like 404 (not found), 500 (server error) or 403 (forbidden). Default error responses often expose distinctive elements from original templates used by the technology. For instance, Apache Tomcat, Spring Boot, Apache, Nginx and IIS all display default pages for specific HTTP status codes that reveal telltale signs about the technology stack.

Even with modest customisation, it is possible to fingerprint the technology used by analysing HTML tag structures, embedded comments or specific phrasing used within the page.

Sending malformed HTTP requests to a web server typically triggers error responses that expose identifying details about the underlying technology. This tactic effectively turns an inadvertent server misconfiguration into a golden opportunity to discover vulnerabilities within that environment.

For example, a malformed HTTP request might involve sending a request with an invalid HTTP version or method, as shown in the examples below:

If the web server is not configured to handle such requests, they can trigger an error in the technology used by the web server that potentially exposes the banner. As such, this technique can be an effective way to gather intelligence on the server’s configuration, despite its attempts to hide its identity.

Default file and directory structures also play a major role in HTTP fingerprinting. Analysing directory naming conventions is a great way to discover which framework the web server is using, while file extensions can reveal the underlying programming language. 

 often contain version details that confirm elements of the technology stack. Once these structures are mapped, you can strategically focus your HTTP recon efforts on known vulnerabilities tied to the identified framework or language.

Web servers and frameworks implement unique session cookie parameters that reliably indicate which programming language or framework is being used, even when hidden behind a reverse proxy. The complexity of configuring and masking these identifiers across diverse environments makes analysing cookie parameters a consistently reliable way to fingerprint a server.

By pinpointing the back-end architecture in place, you can focus your pentesting strategy on technology-specific vulnerabilities rather than wasting time on irrelevant exploits.

Examples of cookie parameter names used by various technologies:

Third-party services Wappalyzer and Shodan are excellent fingerprinting resources, in part thanks to their large databases of technology signatures collected from a wide range of web applications. They can be used to efficiently fingerprint your target's web server by aggregating historical data and patterns that might not otherwise be obviously visible, saving you significant time and effort.

Shodan provides useful insights about a web application’s open ports and running services. Also storing HTTP responses from the web application, Shodan is a great tool for leveraging the techniques described earlier to analyse HTTP response headers.

Wappalyzer, on the other hand, detects the underlying technology stack of a web application. This browser extension reveals frameworks, programming languages and third-party services powering websites. Lookups might confirm suspicions you had about the presence of certain technologies, or reveal components that would have stayed entirely hidden if you relied on manual inspection.

By combining this passively-collected data with your active findings, you gain a full-spectrum view of the target’s architecture and give yourself the best chance of spotting inconsistencies that signal potential misconfigurations.

A crucial first step for protecting against HTTP fingerprinting is to suppress or customise server headers. Removing or rewriting version information in 

 headers should hide the real server banner. Creating misleading values forces adversaries to expend additional effort guessing or probing for system details, and complicates any automated exploits that rely on easily accessible version data.

Default responses supplied by technologies such as Tomcat or Nginx often include logos or text that reveals a server’s identity. Replacing these default pages – or at least deleting the exposed version – makes HTTP fingerprinting significantly more difficult for the attacker.

To give some specific scenarios, with Apache, administrators can modify the 

. In Nginx, similar results can be achieved by setting the 

 file. For Tomcat, achieving this involves editing the 

Another defensive layer can come in the form of web application firewalls that intercept and modify outbound HTTP headers.

Removing unnecessary files and directories is also advisable. Items such as 

 can contain explicit technology references or version details. If these files are no longer needed, they should be deleted; if they 

 needed, then an access control should be configured to prevent unauthorised users from viewing their contents.

Regularly reviewing server configurations and conducting periodic vulnerability assessments can ensure that header customisations and file restrictions remain effective against evolving fingerprinting techniques. Automated monitoring tools like intrusion detection systems and continuous compliance scanners can also alert administrators to any configuration drifts or the resurfacing of sensitive default responses.

Conclusion: A more targeted approach to bug hunting

So now you’re familiarised with an essential recon technique in the arsenal of security researchers and Bug Bounty hunters.

You’ve learned about various methods and tools for performing HTTP fingerprinting on web applications, in order to extract valuable information about the underlying technology stack.

Now you have some foundational knowledge about how different technologies respond to various techniques and what information they might expose.

Some methods work better than others in certain contexts. Being able to deploy them all, in relevant combinations for the environment, can help you build a profile of your target’s attack surface.

By mastering HTTP fingerprinting, you therefore gain a strategic advantage in identifying vulnerabilities, since you can tailor your exploitation techniques to the attack vectors you’ve uncovered. In other words, it means less wasted time and a quicker path to real vulnerabilities – and real Bug Bounty rewards. 

*The Apache reverse proxy is the most likely

Recon series #3: HTTP fingerprinting – sleuthing for a web application’s hidden vulnerabilities

The US House of Representatives has passed a bill that would oblige federal contractors to implement a vulnerability disclosure policy (VDP).

If the bill subsequently passes the Senate, security researchers would have a formalised process through which to responsibly report vulnerabilities in systems belonging to providers of goods and services to the federal government.

Federal Contractor Cybersecurity Vulnerability Reduction Act

 (PDF), the Office of Management and Budget (OMB) would recommend updates to contract requirements and language around implementing VDPs within the Federal Acquisition Regulation (FAR), which governs federal procurement processes.

The OMB would consult with the director of the Cybersecurity and Infrastructure Security Agency (CISA), the National Cyber Director and the director of the National Institute of Standards and Technology (NIST) in drafting these recommendations.

The bill requires that the Department of Defense (DOD) must conduct a similar review with regards to defence contractors.

VDPs would have to be consistent with NIST guidelines.

“Cyber threats don’t wait for bureaucratic red tape. This legislation ensures federal contractors meet the same high cybersecurity standards we expect from federal agencies,” 

, the congressional Republican who introduced the bipartisan bill in 2023. “By eliminating vulnerabilities before our adversaries can exploit them, we’re reinforcing America’s cyber resilience in real time.”

The bill has now been referred to the Committee on Homeland Security and Governmental Affairs.

VDPs have already been rolled out across US government departments, including the 

As of September 2024, CISA’s own VDP platform had, three years after launch, triaged over 12,000 submissions from 3,200 security researchers, resulting in 

 (PDF), 2,000 of which had been remediated at that point.

News of the US VDP bill’s passage through the house came just a few days after the UK Home Office, which is responsible for immigration, security and law and order, 

However, the announcement did not meet with universal acclaim. The CyberUp campaign has 

 that the VDP, which prohibits researchers from breaking “any applicable law or regulations”, is undermined by the fact that “the Computer Misuse Act – an archaic law written in 1990 when just 0.5% of the population had internet access – blanketly criminalises all unauthorised access to computer systems, irrespective of intent or motive to act in the public interest.”

Piecemeal efforts to reform the law are currently 

VDPs have long been seen as best practice within the cybersecurity industry, with the 

 guidelines on vulnerability disclosure a significant milestone. However, in recent years the rate of adoption in the public and private sector has accelerated, partly in anticipation of regulatory requirements.

 for instance requires that vendors of products with digital elements (PDEs) implement VDPs. The 

UK Product Security and Telecommunications Infrastructure (PSTI) Act

 mandates similar obligations for Internet of Things (IoT) manufacturers.

Secure, coordinated vulnerability disclosure

As a secure channel for coordinated vulnerability disclosure, a VDP shows your customers that you take security seriously and can usefully complement a 

 aligned with industry best practices and your specific needs and integrate it into your website. Other product features:

Unified interface for receiving reports and managing vulnerabilities

Receive only valid, actionable reports thanks to our in-house triage service

Triage team can evaluate bug severity and liaise with security researchers

End-to-end encryption ensures confidential communication

US House passes bill mandating vulnerability disclosure policies for federal contractors

, asked participants to perform a punycode attack to overwrite source code, escape a sandbox and perform a JavaScript code injection which exposes the flag.

Want to create your own monthly Dojo challenge? Send us a message on X!

 feeds to be notified of upcoming challenges.

Read on to find out how one of the winners managed to solve the challenge.

TALKIE PWNII #4: VIDEO CHALLENGE WRITE-UP

We want to thank everyone who participated and reported to the Dojo challenge. Below is the best write-up overall:

The challenge revolves around a web application that allows users to purchase and update websites. However, the application is vulnerable to code injection due to improper handling of user input in the 

 function. The application uses Node.js's 

 module to execute JavaScript code within a sandboxed environment. The issue arises from the use of 

, which is intended to restrict code execution but is improperly implemented, allowing an attacker to escape the sandbox and execute arbitrary code on the host machine.

This vulnerability is particularly dangerous because escaping the 

 context can lead to remote code execution (RCE), granting an attacker access to sensitive system resources and executing commands.

During the initial reconnaissance phase, a thorough code inspection was conducted to understand the application's architecture and functionality. The application is built using Node.js and utilizes the 

 module to execute user-provided JavaScript in an isolated environment. The code defines a sandboxed execution context and processes user input before passing it to 

. Additionally, various utility functions are implemented to handle user requests and manage application logic. By analyzing the source code, we can identify how input is handled, processed, and executed, which provides insight into potential security risks and areas requiring further scrutiny.

On the initial code analysis, the tech stack was analyzed, and it wasn't tough to realize that the underlying stack was Node.js, sqlite3 for database and ejs for templating. The first block of code is the main method, which handles the user input and handles the main application functionality.

 function executes,, it first initializes the db with 

 function which populates the database with two websites 

, by decoding potentially URL-encoded strings. Next, it is checked if the 

 variable is an empty string. In case it is empty string, the function returns early with 

The next try-catch block was an important block in uncovering this vulnerability.

The provided code is responsible for handling the registration of a website by checking its availability and, if available, proceeding with its purchase. The process follows a structured approach to ensure that duplicate registrations do not occur.

, which queries the database to check if the provided website name already exists. If the website is found in the database, it means it has already been registered by another user. If the website is already taken (

), the function immediately returns an error message:

If the website is available, it is converted to Unicode using 

. This step is crucial because domain names can be represented in Punycode, which encodes international characters into ASCII. It means if an attacker provides the punycode encoded version of an existing website, it escapes the availability check and gets converted back to Unicode version in this step.

In case an invalid website is given, it throws the error, "Invalid website given!"

Next lines of code is responsible for updating the content of a website for the client after checking if the website already exists in the database.

This code retrieves all websites from the database, checks if the provided website exists, and if found, updates its content with the given source code. The update stops once the first matching website is found. This method is crucial for injection of the user provided payload.

And here comes the most crucial block of the code.

This section of the code is responsible for verifying the source code of the website 

 by executing it in a controlled and secure environment. The code first retrieves the source code associated with the specified website from the database using the 

 function. Once the source code is obtained, it is run in a sandboxed environment using 

. This approach ensures that the source code is executed in isolation from the rest of the system, effectively preventing any unintended side effects or security vulnerabilities from affecting the broader environment.

The execution occurs in a context created by 

. If the source code contains errors or causes an exception during execution, the error is caught by the 

 block. When an error occurs, the function 

 is called to notify the infrastructure team about the issue, and the main function returns an error message indicating that the code verification process failed with the message "Our code is broken!"

Having understood the complete application logic, it is now easy to look for the security flaws. There is a normal flow when the user enters an available website and a valid or empty code, it displays the "Nice Catch - You're all set!" message.

 which already exists on the database, it shows that it has been already registered by another user. This blocks one from updating the source code and executing it in the sandbox environment.

 payload that escapes the availability check was required. The simple idea (and also mentioned in the hint) is to convert the website 

 to punycoded version which came out to be 

 check and gets converted back to unicoded version once availability check is done. So this can be used to update the source code of the website that could potentially escape the sandbox and execute code that can read the environment variables.

Now a payload that escapes the payload and can read the environment variables was required. On the pursuit of payload for 

, I came across multiple resources and tried a lot of different payloads. I finally managed to come up with the payload that escapes the JavaScript sandbox.

 Function object. A JavaScript function has a characteristic in which it accepts code as string and will then execute it. Our attack will exploit this fact and — along with a immediately invoked function execution, known as IIFE for short — will print the environment variables for the running Node.js process.

Which displayed the environment variables and you've pawned it modal.

I then changed the payload to display just the FLAG env variable,

With this injection, it is possible to read the environment vaiables of the Node.js process that is executing. The punycoded website name 

 escaped the availability check and allowed to update the malicious source code in the website i.e. 

this.constructor.constructor("console.log(process.env.FLAG)")()

 that exposes the sensitive env variables to the attacker.

An attacker could exploit this vulnerability to execute arbitrary Javscript code and disclose internal information like environment variables. If users are allowed to run custom code, they have complete access to the Node.js server runtime and can spawn processes, access the file system, and more.

Use Secure Sandboxing Libraries: Libraries like vm2 provide stricter isolation and prevent prototype pollution attacks.

Restrict Global Access: Limit access to built-in objects like Function, eval, and require by explicitly defining a safe environment.

Implement input sanitization to block malicious payloads

Dojo challenge #39 - Phishing winners & writeup

Are we entrusting too much coding to AI, too soon? The results of two new studies, along with fresh concerns expressed elsewhere, suggest we might be. 🤖

Exhibit A is a think piece that achieved the remarkable feat of eliciting a 

thoughtful, non-provocative response on X from Elon Musk

collective atrophy of basic programming skills

 to the loss of human muscle memory when it comes to navigating cities in the Google Maps era. “We’re at this weird inflection point in software development,” began the 

. “Every junior dev I talk to has Copilot or Claude or GPT running 24/7,” continued Namanyay Goel, a developer and entrepreneur. “They’re shipping code faster than ever. But when I dig deeper into their understanding of what they’re shipping? That’s where things get concerning,” he continued, before warning ominously of long-term adverse consequences of this rush to over-automate software development. 💡

Tech and cyber expert Andy Ellis expressed similar concerns in the CISO Series Podcast. In an episode titled ‘

Our Developers’ New Motto is 'LLM Take the Wheel

’, he cited Joel Spolsky’s 2002 article on ‘

risks posed by an over-reliance on LLMs for software development

: “When you see your code behave in a certain way, you might be like: ‘Oh, I probably have a memory leak, or I’m not running on big enough hardware’, whatever it is. And when you lose that understanding of the knowledge of complexity of what’s going on underneath it, you sort of don’t have the ability to reason about what’s happening. And if you let AI write your code […] that’s an abstraction barrier between your prompt engineering and some other level of code, which then has more abstraction barriers below it.” 🧩

Keeping developers connected to their code – especially the how to avoid insecure code and its consequences – is something our 

by leveraging vulnerability reports for internal training purposes

. The insights our ethical hackers provide, notably through proofs of concept for bugs and suggested mitigations, can teach devs secure development best practices and reduce the number of security flaws created. 🧠

Back to bashing AI now and new research revealing how 

AI coding assistants might be eroding code quality

. Based on analysis of 211 million lines of code, a 

 found that there were eight times the number of code blocks with more than four duplicated lines in 2024 compared to 2023. Higher code duplication and reduced refactoring is generally seen as leading to higher maintenance costs, lower code readability and a wider proliferation of vulnerabilities. ⚠️

If this was heartening news for coders worried about being eclipsed and ultimately replaced by AI, then they will be further cheered by an admission by OpenAI researchers that 

even frontier models “are still unable to solve the majority” of coding tasks

, neither OpenAI’s o1 and GPT-4o models nor Anthropic’s Claude 3.5 Sonnet could match human devs in benchmarking tests around “resolving bugs and implementing fixes to them, or management tasks that saw the models trying to zoom out and make higher-level decisions”. 🧐

black-box nature of AI outputs is a problem for security researchers

 just as it is for developers. In ‘The Pitfalls of 'Security by Obscurity’ And What They Mean for Transparent AI’, 

researchers from New York University have argued

 that excessive (albeit partly understandable) secrecy about the inner workings of AI models is undermining security research, especially when their complexity makes transparency in this domain only more imperative. The researchers propose measures such as third-party audits, structured vulnerability disclosure programs, and the creation of shared benchmarks and datasets to evaluate AI safety and fairness. ⬛

AI also comes up (but of course it does!) in an interesting 

, but let’s take a break from AI and highlight another noteworthy quote from the Q&A: “My biggest challenge – but it also applies to all CSOs and CISOs – is being able to 

articulate what are technical attacks, technical vulnerabilities into business impact

,” Marnie Wilking told Infosecurity Magazine. “Being able to go back and forth and bridge that communication gap is a very important skill set but also a very difficult job. At the end of the day, what the leadership team wants to know, what we should be worried about is how it impacts our partners, our customers and our ability to deliver to customers.” 👨💼 (Incidentally, understanding the true business impact of vulnerabilities is a cornerstone of our own business model, to the end of prioritising the most critical bugs first, as our head of triage discussed in an 

 about YesWeHack’s in-house triage service).

“I’ve been watching the litigious world that we’re now in, and I’m not pleased at all,” said Kevin Winter, global CISO at Deloitte, in another illuminating interview. “I didn’t think it would go this direction,” he said, in relation to 

, which have introduced mandatory reporting of “material” cybersecurity incidents, and 

exposed CISOs to the risk of criminal liability

 for making the wrong calls over security incidents. ️⚖️ Winter featured alongside Richard Marcus, CISO at AuditBoard, in the 

CISOs will note with interest that any UK-based employees using iCloud will see their security protections reduced after Apple turned off end-to-end encryption for UK-based users on Friday. As reported by 

, called Advanced Data Protection (ADP), in response to British government requests for a backdoor, to assist with data retrieval related to criminal investigations. An Apple spokesperson said: “As we have said many times before, we have never built a backdoor or master key to any of our products or services and we never will.” A former British government minister has 

 the security risks of users losing access to ADP. In contrast, Dr Joseph Lorenzo Hall, distinguished technologist at the Internet Society, was “

With spring on the horizon, our first conferences of the year are hoving into view. First up for the YesWeHack team is 

. Pitched by the organisers as “the most exclusive cybersecurity event in the world”, Next IT Security is a forum for meetingC-level cybersecurity decision-makers for a “day of expert-led discussions” about the most pressing cybersecurity challenges of the moment. Our very own Sam Lowe and Jan Nieminen will be in attendance to discuss the benefits of crowdsourced security, including during a five-minute ‘Fire Starter’ session at 10:50am.

) to demo the YesWeHack platform and field questions about Bug Bounty and vulnerability management, as well as to hand out some swag. If you want to find out more about how to strengthen your security posture cost-effectively, you can find us on booth D1. The organisers are expecting 20,000 visitors from 103 countries for the 17th edition, whose theme is ‘zero trust’.

Read this monthly roundup even sooner by subscribing to 

 – our LinkedIn newsletter curating news, insights and inspiration around offensive security topics like Bug Bounty, vulnerability disclosure and management, pentest management and attack surface protection.

Are you a bug hunter or do you have an interest in ethical hacking? Check out our ethical hacking-focused sister newsletter, 

 – offering hunting advice, interviews with hunters and CTF-style challenges, among other things.

Junior devs ‘can’t actually code’, AI coding risks, security researchers decry inscrutable AI – OffSec roundup for CISOs

Ever wondered whether you ever missed a hidden subdomain that would have unlocked a critical vulnerability and a large bounty reward?

In this article, you will discover how cutting-edge subdomain enumeration techniques, both passive and active, can reveal the unseen corners of your target’s infrastructure.

We’ll explain the advantages of various techniques, recommend enumeration tools for executing them, and show you how to implement these techniques, supported by illustrative examples performed on a real public bug bounty program (that of 

When Bug Bounty hunting or conducting a pentest, subdomain enumeration is a crucial first reconnaissance step before you actually start hacking – maximising the exposed attack surface and therefore your chances of finding vulnerabilities.

Enumerate subdomains using public databases

Using Google dorking to enumerate subdomains

Performing HTTP probes on collected domains

Subdomain enumeration is a technique for collecting subdomains from a domain owned by the program you are testing. The goal is to enumerate as many assets from the program as possible, to gain an understanding of total attack surface and how the infrastructure works. Once you’ve collected all these subdomains, it's easier to scale up your attacks and achieve better results.

The YesWeHack Blog

Recon series #3: HTTP fingerprinting – sleuthing for a web application’s hidden vulnerabilities

US House passes bill mandating vulnerability disclosure policies for federal contractors

Dojo challenge #39 - Phishing winners & writeup

Recon series #3: HTTP fingerprinting – sleuthing for a web application’s hidden vulnerabilities

Junior devs ‘can’t actually code’, AI coding risks, security researchers decry inscrutable AI – OffSec roundup for CISOs

Recon Series #2: Subdomain enumeration – expand attack surfaces with active, passive techniques

Bounty Grid Boost: Ethical Hackers Invited to Strengthen the Security of the French Government’s Digital Services

Junior devs ‘can’t actually code’, AI coding risks, security researchers decry inscrutable AI – OffSec roundup for CISOs

Top web hacking techniques of 2024, McDelivery hijack, 4D SOTA jailbreak – ethical hacker news roundup

XSS attacks and exploitation: The ultimate guide to cross-site scripting

Vulnerability management reboot sought, CISOs more influential in boardroom, Trump’s cyber overhaul – OffSec roundup for CISOs

Top web hacking techniques of 2024, McDelivery hijack, 4D SOTA jailbreak – ethical hacker news roundup

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us