• Web security is often associated with backend protection, but frontend vulnerabilities can be equally dangerous. From Reflected XSS to Missing CSP headers, overlooking security at the client side can expose your application to a range of attacks.

  • In this article, we’ll explore 7 common frontend vulnerabilities — what they are, why they matter, and how you can secure your app against them.

1. 🚨 Reflected XSS (Cross-Site Scripting)



What is it?

  • Reflected XSS occurs when an attacker injects malicious scripts via the browser's URL (e.g., query parameters), which are then immediately reflected back by the web app without sanitization.

Frontend Example:

Hello, !

  const name = new URLSearchParams(window.location.search).get("name");
  document.getElementById("name").innerHTML = name;

Exploit URL:

https://yourdomain.com?name=alert('XSS')

How to fix it:

  • Always sanitize or escape user input before rendering.
  • Use textContent instead of innerHTML when inserting text. 
document.getElementById("name").textContent = name;

2. 🛑 Missing HSTS Header



What is it?

  • HSTS (HTTP Strict Transport Security) forces browsers to interact with the site over HTTPS only.

Why it matters?

  • Without it, attackers could intercept or downgrade requests from HTTPS to HTTP.

How to fix it (on server):

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Note: While this is a server-side header, frontend developers must be aware during deployment and review that HSTS is enforced, especially for SPAs hosted on CDNs or static hosting platforms.

3. 📝 Log Forging



What is it?

  • When user input is logged directly without sanitization, attackers can inject line breaks or misleading content into logs (e.g., support tickets, error tracking).

Example:

console.log("User input: " + userInput);

Attack input:

\n[ERROR] Something went wrong

Resulting log:

User input:
[ERROR] Something went wrong

How to fix it:

  • Encode or sanitize line-breaking characters like \n, \r, or delimiters before logging.

4. 🔁 Client DOM-Based Open Redirect

What is it?

  • If your frontend redirects users based on a query string or fragment without validation, attackers can trick users into visiting malicious sites.

Example:

const redirectTo = new URLSearchParams(window.location.search).get("next");
window.location.href = redirectTo;

Exploit:

https://yourapp.com?next=https://malicious-site.com

How to fix it:

  • Allow only known, whitelisted URLs.
  • Use relative paths, not full URLs from query strings. 
const allowedRoutes = ["/dashboard", "/profile"];
if (allowedRoutes.includes(redirectTo)) {
  window.location.href = redirectTo;
}

5. 🖼️ Use of Without sandbox

What is it?

  • Using iframes without sandboxing can give embedded content more power than it should have (e.g., running JS, submitting forms, top-level navigation).

Example (vulnerable):

Better:

Best practice:

  • Use a strict sandbox attribute with only required permissions:

6. 📦 JSON Hijacking

What is it?

  • An older but still relevant attact where sensitive JSON data ( like user info) is exposed via GET request, allowing attacker to "hijack" it via tags.

How?

  • If your API returns user JSON data on GET requests like: 
fetch("/user-info")

An attacker can include:

Fixes:

  • Use proper Content-Type: application/json.
  • Require authenticated POST requests for sensitive data.
  • Add anti-CSRF measures.

7. 🔐 Missing CSP (Content Security Policy)



What is it?

  • CSP is a browser feature that helps prevent XSS by declaring what content is allowed to load or execute.

Why it matters?

  • Without it, attackers can inject inline scripts or load malicious scripts.

Example CSP header:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

Frontend impact:

  • Avoid inline and
  • Use hashes or nonces if inline scripts are necessary.