Skip to main content

Text Based Injection | Content Spoofing | Low Impact Common Web Vulnerability

Text Based Injection: Text injection or Text-Based Injection(TBI) is an injection in which user input is reflected as it is in the application response as plaintext. This is one of the ways to perform content spoofing also referred to as content injection or virtual defacement which can be used in phishing attacks.

An application is vulnerable to Text injection when it does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, or from the URL only that is reflected back to the user. The user will be presented with a modified page under the context of the trusted domain. 

Attack Type: Client-Side Vulnerability
Severity: Low

Audit Guidelines

Text injection can be easily found where
1) User input via parameter or directly in the URL is reflected in the page response.
2) Content-Type: text/plain
3) Application is giving default error pages

Proof of Concept

If you research little more to understand why it is happening and what is the issue here. You will get an answer for 'what is the issue' that the application is giving a default error page. 

For 'why it is happening', we know the answer, right? 
Anyway, the answer is user input via parameter or directly in the URL is reflected in the page response.

Error Page
Error page

Modified Error Page
 Modified Error Page

How Google Do it
Google handles the error pages really well. Here is the screenshot for your reference.
Good Handling of user-supplied input in URL by Google


An attacker can use text injection vulnerability to present a customized message on the application that can phish users into believing that the message is legitimate. The intent is typical to tick victims, although sometimes the actual purpose may be to simply misrepresent the organization or an individual. This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust. As a side note, this attack is widely misunderstood as a kind of a bug that brings no impact. 


The application should only accept the values and types that are defined for parameters and should be checked at the server-side whether there is change content, if there is change, then the application should reject that request. Also, never construct and send messages via URL in the page response. Prefer using messages predefined in a property file.

For Default Error pages

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is user-friendly in addition to being a good security practice, and can be done by specifying custom error pages for error codes like 404, 403, 500, etc.