HTML and JavaScript form the client-side foundation of every web application. Because browsers automatically parse and execute HTML markup and JavaScript code, any untrusted input that reaches these layers can lead to severe vulnerabilities. Understanding how HTML and JavaScript behave—and how they can be abused—is critical for evaluating client-side security.

HTML/JS security focuses on how attackers manipulate markup, DOM behavior, event handlers, JavaScript execution contexts, and browser trust models to exploit vulnerabilities such as XSS, DOM manipulation, injection attacks, session theft, and UI abuse.

HTML as an Attack Surface

HTML defines the structure of the page. When user-controlled data appears inside HTML without validation or escaping, attackers can break out of the intended context and inject malicious markup or scripts.

Common injection points in HTML:

• innerHTML assignments

• unescaped form fields

• reflected user content in pages

• attributes such as title, alt, value, href, and src

• dynamic DOM updates

• custom HTML components

HTML does not distinguish between trusted and untrusted content; the browser renders whatever is provided.

Dangerous HTML Contexts

Plain HTML Context

Vulnerable insertion:

<div>NAME: USER_INPUT</div>

If input includes:

<script>alert(1)</script>

the browser executes it.

Attribute Context

<input value="USER_INPUT">

Payload:

" autofocus onfocus=alert(1) x="

modifies the attribute and executes JavaScript.

URL Attributes

<a href="USER_INPUT">Link</a>

If attacker uses:

javascript:alert(document.cookie)

the browser executes code when clicked.

Event Handlers

Many HTML elements support embedded events:

onclick
onload
onfocus
onmouseover
onerror

If user-controlled content reaches these, code executes immediately.

HTML Injection vs XSS

HTML injection occurs when attackers inject markup but cannot execute JavaScript. However, HTML injection often becomes XSS if they can use event attributes or scripting contexts.

Example:

<b>Injected</b>
<img src=x onerror=alert(1)>

This turns harmless HTML injection into active script execution.

JavaScript as an Attack Surface

JavaScript runs with the full privileges of the webpage:

• access to cookies (if not HttpOnly)

• access to DOM

• ability to send requests

• ability to read responses

• access to localStorage/sessionStorage

If an attacker injects JavaScript, they effectively control the user’s session.

Dangerous JavaScript Coding Patterns

Using innerHTML to Insert Content

element.innerHTML = userInput;

If userInput contains malicious HTML/JS → immediate XSS.

Using document.write

document.write(userInput);

This allows script injection directly into DOM.

Using eval or Function

eval(userInput);
new Function(userInput);

Any string becomes executable code.

Unsanitized URL parameters

var name = location.search.slice(6);
document.getElementById('greet').innerHTML = name;

A single query parameter can inject malicious scripts.

Dynamic DOM creation without sanitization

el.insertAdjacentHTML("beforeend", userContent);

This executes any embedded scripts or events.

Sensitive Client-Side Data

Developers must avoid storing:

• tokens

• API keys

• passwords

• user secrets

• auth states

in JavaScript, localStorage, or cookies accessible via JS.
An XSS flaw compromises all such data instantly.

Common HTML/JS Weaknesses

1. DOM-Based XSS

Occurs entirely in JavaScript.
Example:

search.innerHTML = location.hash.substring(1);

Payload:

#<img src=x onerror=alert(1)>

Script executes because JS writes untrusted input into DOM.

2. Client-Side Validation Bypass

JavaScript validation can be bypassed by:

• disabling JS

• editing HTML

• modifying requests in Burp

• directly calling API endpoints

Security cannot rely on client-side validation.

3. Prototype Pollution (JS Specific)

JavaScript inherits values through __proto__.
If attacker injects:

{"__proto__": {"isAdmin": true}}

then:

anyObject.isAdmin → true

Prototype pollution leads to privilege escalation in JS-heavy apps.

4. Open Redirects

If JS constructs URLs insecurely:

location.href = userInput;

Attackers redirect victims to phishing or malware sites.

5. UI Redressing / Clickjacking

HTML frames:

<iframe src="target.com"></iframe>

combined with invisible layers trick users into performing unintended actions.

6. DOM Clobbering

If attacker injects HTML elements that override global JS variables:

<input id="config" value="malicious">

JavaScript may treat this as an object and break logic or execute code.

7. Unsafe Third-Party Scripts

Scripts loaded from external sources can:

• be modified

• serve malicious payloads

• expose session data

• log keystrokes

If a CDN or external JS file is compromised, every user is compromised.

8. localStorage Abuse

localStorage is accessible via all JS on the page.
XSS + localStorage = instant account takeover.

Example:

localStorage.getItem('authToken')

Attackers extract token through injected JavaScript.

9. Dangerous HTML Tags

HTML supports powerful, abusable tags:

<script>
<object>
embed>
iframe>
svg>
math>

<svg> alone can execute:

<svg onload=alert(1)>

Practical HTML/JS Security Testing Workflow

Step 1: Inspect Client-Side Code

Look for JavaScript patterns involving:

• innerHTML

• eval

• atob/btoa

• JSON.parse with attacker-controlled data

• URL parameter parsing

Step 2: Modify UI Inputs

Test injecting markup in:

• forms

• comment sections

• profile names

• search boxes

• URL parameters

Example test payload:

"><script>alert(1)</script>

Step 3: Check DOM Manipulation Locations

Search code for:

innerHTML
insertAdjacentHTML
document.write
outerHTML

Any usage with untrusted input is dangerous.

Step 4: Test Attribute Injection

Insert:

" onfocus=alert(1) "

If element renders and event fires, attribute context is injectable.

Step 5: Test JS Object Injection

If JavaScript reflects JSON:

{"name":"attacker"}

Try:

{"name":"attacker","__proto__":{"isAdmin":true}}

Step 6: Inspect localStorage and sessionStorage

Look for sensitive values such as:

authToken
sessionID
userRole

If stored client-side, XSS can extract it.

Step 7: Test for UI Redressing

Try embedding the target:

<iframe src="https://target.com">

If frame loads → clickjacking possible.

Step 8: Inspect External Scripts

Check script sources:

<script src="http://cdn.example.com/script.js">

HTTP scripts allow MITM injection.
Compromised CDNs lead to widespread compromise.

Why HTML/JS Weaknesses Occur

Root causes:

• mixing untrusted data into HTML/JS

• overreliance on client-side validation

• unsafe DOM manipulation

• storing sensitive data in client storage

• using dangerous functions like eval

• loading insecure third-party scripts

• missing Content Security Policy

• misunderstanding browser execution contexts

HTML and JS treat all loaded content as trusted unless explicitly restricted.

Impact of HTML/JS Security Flaws

These vulnerabilities allow:

• XSS (most common and dangerous)

• session token theft

• credential theft

• keylogging

• DOM manipulation

• phishing attacks

• account takeover

• redirecting victims to malicious pages

• privilege escalation via prototype pollution

• full compromise of client-side behavior

Because the browser trusts content from the domain, any injected script gains complete control over the user session.

Intel Dump

• HTML/JS security issues arise when untrusted input reaches the DOM or scripting context.

• Dangerous JS patterns include innerHTML, eval, document.write, and unsafe parsing of URL parameters.

• HTML injection becomes XSS when attackers use event handlers or scripting tags.

• Client-side validation cannot enforce security; bypass is trivial.

• Prototype pollution, localStorage exposure, open redirects, and DOM clobbering are major JS-specific risks.

• Impact includes session hijacking, XSS, redirect attacks, and full client-side compromise.