DEV Community

Cover image for 🛡️ 7 Frontend Security Vulnerabilities You Should Know (And Fix)
Devam Chaudhari
Devam Chaudhari

Posted on

🛡️ 7 Frontend Security Vulnerabilities You Should Know (And Fix)

#webdev #vulnerabilities #security

  • 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:

<!-- A vulnerable example -->
<p>Hello, <span id="name"></span>!</p>
<script>
  const name = new URLSearchParams(window.location.search).get("name");
  document.getElementById("name").innerHTML = name;
</script>
Enter fullscreen mode Exit fullscreen mode

Exploit URL:

https://yourdomain.com?name=<script>alert('XSS')</script>
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

Attack input:

\n[ERROR] Something went wrong
Enter fullscreen mode Exit fullscreen mode

Resulting log:

User input:
[ERROR] Something went wrong
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

Exploit:

https://yourapp.com?next=https://malicious-site.com
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

5. 🖼️ Use of Without sandbox </h3> <p><br/></p> <p>What is it?</p> <ul> <li>Using iframes without sandboxing can give embedded content more power than it should have (e.g., running JS, submitting forms, top-level navigation).</li> </ul> <p>Example (vulnerable):<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>&lt;iframe src="https://third-party.com/form.html"&gt;&lt;/iframe&gt; </code></pre></div> <p></p> <p>Better:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>&lt;iframe src="https://third-party.com/form.html" sandbox&gt;&lt;/iframe&gt; </code></pre></div> <p></p> <p>Best practice:</p> <ul> <li>Use a strict sandbox attribute with only required permissions: </li> </ul> <div class="highlight"><pre class="highlight plaintext"><code>&lt;iframe src="..." sandbox="allow-scripts allow-forms"&gt;&lt;/iframe&gt; </code></pre></div> <p></p> <hr/> <h3> <a name="6-json-hijacking" href="#6-json-hijacking" class="anchor"> </a> 6. 📦 JSON Hijacking </h3> <p><br/></p> <p>What is it?</p> <ul> <li>An older but still relevant attact where sensitive JSON data ( like user info) is exposed via GET request, allowing attacker to &quot;hijack&quot; it via <code>&lt;script&gt;</code> tags.</li> </ul> <p>How?</p> <ul> <li>If your API returns user JSON data on GET requests like: </li> </ul> <div class="highlight"><pre class="highlight plaintext"><code>fetch("/user-info") </code></pre></div> <p></p> <p>An attacker can include:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>&lt;script src="https://yourdomain.com/user-info"&gt;&lt;/script&gt; </code></pre></div> <p></p> <p>Fixes:</p> <ul> <li>Use proper Content-Type: application/json.</li> <li>Require authenticated POST requests for sensitive data.</li> <li>Add anti-CSRF measures.</li> </ul> <hr/> <h3> <a name="7-missing-csp-content-security-policy" href="#7-missing-csp-content-security-policy" class="anchor"> </a> 7. 🔐 Missing CSP (Content Security Policy) </h3> <p><br/><br> What is it?</p> <ul> <li>CSP is a browser feature that helps prevent XSS by declaring what content is allowed to load or execute.</li> </ul> <p>Why it matters?</p> <ul> <li>Without it, attackers can inject inline scripts or load malicious scripts.</li> </ul> <p>Example CSP header:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; </code></pre></div> <p></p> <p>Frontend impact:</p> <ul> <li>Avoid inline <script> and <style> tags.</li> <li>Use hashes or nonces if inline scripts are necessary.</li> </ul>

Top comments (0)