DEV Community

Cover image for 7 Web Security Mistakes to Avoid (As a Developer)

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, ...
Collapse
 
brense profile image
Rense Bakker

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.

Collapse
 
myrddral profile image
Attila Béli • 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. :)

Collapse
 
yaroslaff profile image
Yaroslav Polyakov

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

Collapse
 
adderek profile image
Maciej Wakuła

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
Collapse
 
amadujallow profile image
Amadu Jallow

This was really helpful thanks slot

Collapse
 
devland profile image
Thomas Sentre • Edited

You're welcome! I'm glad that the information was helpful.

Collapse
 
clericcoder profile image
Abdulsalaam Noibi

Thanks for sharing this insightful Tips on web security😇

Collapse
 
devland profile image
Thomas Sentre

You're welcome! I'm glad that the information was helpful.

Collapse
 
koas profile image
Koas

Great post, thanks! I’d always thought that web servers denied serving dot files (.env, .htaccess) by default, I guess that’s not true?

Collapse
 
vdelitz profile image
vdelitz

Nice read! Very concise!

Collapse
 
webystraffic profile image
Nicoletta

Thanks for sharing. It's very informative