Web Security Research

This section presents some of my research and use cases that I have encountered on web applications.

XSS findings

Cross-Site Scripting (XSS) remains one of the most prevalent vulnerabilities across the web. I’ve frequently encountered both reflected and client-side variants, where malicious scripts are stored in local cookies and later injected into the page without proper sanitization.
Through my research, I found that XSS can be triggered not only through typical URL parameter injections but also via modern interfaces such as user chat systems, AI chatbots, and services powered by large language models (LLMs).
These weaknesses can be leveraged to hijack session cookies, perform unauthorized redirects, or establish persistent surveillance. In some instances, the injected script acted as a keylogger, silently capturing keystrokes and transmitting them to a remote server.

Here are a few examples :
In the first image, it’s a reflected XSS. This is the most common type and the one I encounter most frequently.

The second image shows a stored XSS on the server, but based on session cookies. That is, using the PHPSESSID, the page loads certain parameters (in this case, the country and language), but instead of loading the expected values, it retained my script in memory.

SQLI findings

I've encountered SQL injection vulnerabilities on several occasions, particularly on older websites running outdated versions of PHP. When I detect an outdated PHP version, I typically perform in-depth testing specifically targeting this type of flaw.
In most cases, I come across error-based or time-based SQL injections during my manual testing. For other types, such as union-based injections, I usually rely on well-configured and carefully controlled automated tools to assist with detection.

Here are a few examples :
In the first image, this is a time-based blind SQLi. Here, the payload appears to be interpreted twice, resulting in a 10-second delay instead of the 5 seconds initially set in the query.
This example also illustrates why it’s important not to set excessively long delays, as it can overload the database.

In the second image, this is an error-based SQLi where I directly extract an email address from the user database. However, since the server is behind Cloudflare, the email doesn’t appear directly in the raw HTML response. Instead, it is rendered using a JavaScript-based decoding script in the browser.

Exposed API

This is definitely one of the most common issues I come across: exposed APIs, often with weak or missing rate limiting. These flaws typically allow me to enumerate the entire user database, identify administrator accounts, and perform dictionary attacks against multiple admin logins. In this particular case, I wrote a custom Python script to handle the task. Otherwise, I generally rely on tools like ffuf for this kind of enumeration.

Here are a few examples :
In the first image, I gained access to an API route through a subdomain that handled the website’s hosting services. While the main site was protected against brute-force attempts, the API calls on the subdomain were not. This allowed me to enumerate all admin users using a Python script targeting the GraphQL API. From there, I was able to identify which accounts to target with a dictionary attack. Based on the usernames, I also conducted an OSINT phase to better tailor the password wordlist for the attack.

In the second image, we’re again dealing with an API that lacks any rate limiting on requests sent to this endpoint. So similarly, it’s possible to perform dictionary attacks without worrying too much about the number of requests being made.

Information disclosure

Through subdomains, APIs, files, a webpack, or front-end HTML code, I’ve been able to gather interesting information useful for OSINT phases, as well as data that allowed me to directly compromise accounts. Often, I come across API responses that reveal seemingly minor details like a first name or the beginning of a phone number, but also application-related information or even authentication codes.

Here are a few examples :
In the first image, we can see that the verification code is directly hardcoded in the frontend! It's very rare, I agree, but it shows how useful it can be to search for certain keywords in frontend tags to uncover this kind of oddity. This unusual setup allows me to take control of any account. It’s not exactly stealthy, since I’m not intercepting the reset email, so the target is alerted that someone attempted a password reset.

In the second image, it's simply a forgotten subdomain that gives access to various highly sensitive information, including a no-reply email inbox. This inbox used a relatively weak password, which was also reused for other email accounts belonging to the target. These accounts contained sensitive data such as job applications and internal contact mailing lists.

CVE exploitation

Sometimes, application versions are simply outdated. In such cases, the key is to exploit a known CVE to achieve various objectives. To do this, I created a tool that allows me to automate these searches : thiefhunter

Here are a few examples :
In the first image, we see an automated analysis using my custom tool, which enumerates vulnerable versions in use to better guide my testing. In this case, the contact form is vulnerable and allows me to send emails to any recipient on behalf of the no-reply mailbox, with the option to attach files. You can easily imagine how this type of vulnerability could be leveraged for phishing campaigns by sending infected attachments or for other types of social engineering attacks.

In the second image, I used the --vuln function of my tool, which broadens its search scope beyond just WordPress (in the first image, I had used the -wp argument to focus exclusively on WordPress).