secture & code

Drama-free frontend security: mistakes that are (still) made and how to avoid them

Yes, we know you're all about assembling components and making magic with CSS. But if you overlook security, that magic can turn into a nightmare.

In this VLCTechFest talk we went deep into the most common (and dangerous) mistakes in frontend development. Spoiler: many are still being made. Here's a clear and smoke-free summary so they don't blow up in your face.

frontend_security

Why should you care about security in your frontend?

Because your frontend is the first line of defense. Because cookies fly, tokens leak, and attackers don't sleep. And above all, because if it happens to you, it's too late.

2 classic attacks that still sneak in

1. CSRF (Cross-Site Request Forgery)

Your session is alive, and a malicious HTML makes a request on your behalf without your knowledge. Change your email, reset your account... easy if you don't have protection.

How to avoid it:

  • Use CSRF tokens in the forms.
  • Verify the origin of the request.
  • Configure cookies properly (SameSite, HttpOnly, Secure).
  • Better yet: don't use cookies for auth, use a token-based system.

2. XSS (Cross-Site Scripting)

The classic of classics. Use innerHTML, You render without sanitizing inputs, and suddenly someone executes a script on your website.

Real dangers:

  • Stealing the value of cookies or tokens.
  • Redirects to fake pages.
  • Fake interfaces (phishing).
  • Keyloggers in your own app.

Things that help:

  • Use textContent instead of innerHTML.
  • Avoid functions such as evalsetTimeout with strings and new Function, because they execute the code directly.
  • If you use React, do not use dangerouslySetInnerHTML. If its use is mandatory, ensure that there is no executable code with a library such as DOMPurify.

CORS

«In Postman I go» - The drama. Because your browser does respect CORS rules. If you don't properly configure which domains, methods and headers you accept, you're opening doors you shouldn't be opening.

Key recommendations:

  • Do not put the value * for the Access-Control-Allow-Origin header, in production. This way you are allowing access to all domains (if the api is public this does not apply).
  • Limits the methods and headers that are developed in the api.
  • Use the cache so that you do not have to make the preflight request on every request.

Where to store your credentials?

If you use tokens, there are two options: LocalStorage or cookies. Both have pros and cons.

Our hybrid solution:

  • accessToken in LocalStorage (short life, accessible, easy).
  • refreshToken in secure cookie (HttpOnly + Secure + SameSite).

Thus, even if an XSS steals the accessToken, it cannot renew the session or live in your account.

A tip we learned the hard way

Don't wait until you are attacked to get serious about this. We had tokens stolen. It hurt. But we learned. And that's why we put together this talk.

Quick checklist for your project

  •  Do you use CSRF tokens in the forms?
  •  Is your CORS configuration tuned?
  •  Do you capture everything you put in the DOM?
  •  Do you have your cookies set correctly?
  •  Do you store the refreshToken in a safe place?
  •  Do you also review this in staging?

If you can't mark everything... it's time to get down to it.

If you were left wanting more and want to see the full talk:

Thanks to VLCTechFest. See you at the next chat. Or better, before you get hacked.

This talk was made by Javi and Mangel, you know that to read more content from this author you have to go to the end of this post. But if you want to read more posts by Mangel, click here. here.

Frontend

Picture of Javier Motos

Javier Motos

Passionate about programming and learning every day. Currently focused on the frontend although I have always been in all parts of development.
Picture of Javier Motos

Javier Motos

Passionate about programming and learning every day. Currently focused on the frontend although I have always been in all parts of development.

We are HIRING!

What Can We Do