DEV Community

7 Web Security Mistakes to Avoid (As a Developer)

Thomas Sentre on April 24, 2023

As a web developer, it's crucial to prioritize the security of your applications. In today's digital world, cyber threats are constantly evolving, ...

Read full post

Rense Bakker • Apr 24 '23

Storing a jwt in localstorage is fine, aslong as you verify the token on the server, with the server secret that was used to generate the token. Not verifying a jwt on the server, is a security breach, no matter where it was stored.

Attila Béli • Apr 25 '23 • Edited

Came down here to say the same. It's common practice to store the JWT in localstorage. It can only be accessed within its own domain, and even then if someone gets hold of it (for example, attaching a malicious script to a user input and there is no sanitization on submit), the access is short lived because the token will expire as soon as the refresh token does its job or the user logs out. This is why it's important to log out on sensitive websites, to invalidate the access token. :)

Yaroslav Polyakov • Apr 29 '23

Is there any sense to store JWT (access token) in localstorage, but not storing refresh token at same place?

Maciej Wakuła • Apr 28 '23

Outdated libs... Often it is not the dev to decide. I have seen many times dev forced to deliver new features to legacy code (ex. fortran, PHP, perl) without refactoring. Even once a dev was fired for that (more precisely for doing too much on a small feature and as a result not delivering as fast as his waterfall dinosaur manager wanted).
Mamy things might be forced by the organisation - though the list in this article is true for startups and development made by students, small companies and people without experience.
I have seen client-side "security" made by Amex :O Drives with sensitive content on ebay, 30 year old outdated code running on prod in a bank, secrets in github, malicious libs, large apps without any tests and "devs" not knowing anything about testing (or pushing it to "some other team of testers").

The list should be extended by

writing your own version of complex code that is available and open source but you thought you can do it better (what is OK) but then you release this poor custom unmaintainable code to prod
disabling existing tests
outdated documentation
revealing too much api without protecting it (often when 2 separate teams are working on api and on access management)
not using static analysis tools
deployment to prod without testing
using prod data for tests (often on public test servers)
storing user passwords in plain text
no data encryption per user
storing all users data in one place (ex. sqlite) without at least an abstract shared data access control layer that is server side
providing physical access to the device to anyone