DEV Community

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

Posted on • Edited on

7 Web Security Mistakes to Avoid (As a Developer)

As a web developer, it's crucial to prioritize the security of your applications. In today's digital world, cyber threats are constantly evolving, and hackers are always on the lookout for vulnerabilities to exploit. Unfortunately, even small security mistakes can have catastrophic consequences, including data breaches, financial losses, and damage to your reputation.

In this article, we'll discuss the top seven security mistakes that web developers should avoid to keep their applications and users safe.

1. Confusing authentication and authorization

When building web applications, one of the most important aspects of security to keep in mind is the clear distinction between authentication and authorization. These two concepts, while related, serve different purposes and it's essential to understand their differences to ensure the security of your applications.

Authentication is the process of verifying the identity of users, while authorization involves granting or denying access to specific resources or functionalities based on the user's permissions or roles. Confusing these two can lead to serious security vulnerabilities, such as unauthorized access and data breaches. To avoid this mistake, always first implement robust authentication mechanisms to verify user identities and then use proper authorization techniques to control access based on permissions or roles.

2. Storing sensitive data in local storage

Developers sometimes make the mistake of storing sensitive data, like passwords, credit card information, and JWT Tokens in a browser's local storage. This can be dangerous because it makes the data more vulnerable to attacks from hackers.

One of the main problems is that malicious code can be injected into a website, allowing attackers to access and manipulate data stored in local storage. This can lead to unauthorized access to sensitive data.

To avoid this risk, it's important to store sensitive data on the server-side using secure methods, like encryption and access controls. Only store essential information on the client side, and sanitize and validate it properly to prevent attacks. Additionally, make sure to clear or remove any stored data once it's no longer needed to prevent unauthorized access or exploitation.

3. Using outdated libraries and frameworks

Libraries and frameworks are essential tools used in web development to streamline the development process and add functionality to applications. However, using outdated versions of these libraries or frameworks can pose significant security risks.

Outdated libraries and frameworks may contain known security vulnerabilities that have been patched in newer versions. These vulnerabilities can be exploited by malicious users to gain unauthorized access to your web app or compromise its security. For example, an outdated dependency could contain a vulnerability that allows for remote code execution, allowing an attacker to execute malicious code on the server or gain unauthorized access to the underlying system.

To mitigate this risk, it is important to regularly update all libraries and frameworks used in a web application to their latest stable versions. This includes not only the main frameworks or libraries but also any dependencies or plugins used. Additionally, you should stay informed about the lifecycle of the libraries and frameworks they use. Some libraries may no longer be actively maintained, which means that security vulnerabilities may not be patched promptly or at all. In such cases, consider alternative libraries or frameworks that are actively maintained and have a strong track record of timely security updates.

4. Relying solely on client-side security

Client-side security measures, such as input validation and authentication mechanisms implemented in the user's browser, may not be sufficient to protect against attacks. They can be easily bypassed or manipulated by attackers with knowledge of web development and browser tools. Therefore, it's important to implement robust server-side security measures in addition to client-side security to effectively protect your web applications against potential vulnerabilities and attacks.

5. Putting .env File in a Web Server Directory

Putting an environment file (.env) in a web server directory can be a big security mistake. An .env file contains sensitive information like API keys and database credentials that shouldn't be accessible by unauthorized users. If the .env file is in a web server directory, it can be easily accessed by anyone with the URL. For instance, you may find the database password of a real website just by searching in Google because the .env file was left in the public folder of that website. Therefore, it is crucial to store the .env file outside the web server directory or in a location that is not publicly accessible.

It's also essential to limit access to the .env file. Even your teammates should not have access to it unless they need it for specific reasons. Remember, not everyone needs to know the database password or API keys used in your web application.

6. Trusting Third-Party Code

Trusting third-party code is another common security mistake that web developers should be cautious about. Many websites and web applications rely on third-party libraries, plugins, frameworks, and other code snippets to add functionality or streamline development. However, blindly trusting and integrating third-party code without thorough evaluation and validation can introduce potential security risks.

Here are some considerations to keep in mind when dealing with third-party code:

  • Source and Reputation: Always verify the source and reputation of the third-party code you are planning to use. Stick to reputable sources such as official repositories or well-known libraries with a large user base and active community support. Avoid using code from unknown or untrusted sources, as it may contain malicious code or vulnerabilities.

  • Minimal Integration: Only include necessary third-party code and review it for potential security risks

  • Security Configurations: Configure third-party code with security best practices in mind, such as secure authentication and least privilege principles.

  • Regular Audits: Perform regular audits of third-party code and monitor for security updates.

7. Not testing for security vulnerabilities

Skipping security testing can leave vulnerabilities undetected in your web application. Perform regular security assessments, penetration testing, and vulnerability scanning to identify and remediate any security weaknesses.

Summary

Developing a web application requires more than just knowledge of code - it also involves an understanding of potential security risks. As developers, we all strive to write code that is secure and robust, but unfortunately, the common errors mentioned in this article can occur when we're not paying close attention.

By being aware of these top 7 security mistakes, you can take proactive steps to prevent them and create more secure web applications.

THANK YOU FOR READING
I hope you found this little article helpful. Please share it with your friends and colleagues. Sharing is caring.

Connect with me on various platforms

Top comments (11)

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