Have you ever had one of those moments when you feel confident about the code you’ve written — until a VAPT (Vulnerability Assessment and Penetration Testing) team reviews it? Suddenly you’re faced with a sea of red flags and dire warnings. Words like SQL Injection, Cross-Site Scripting, and denial-of-service are thrown around, and you’re left wondering: “Is my code really that insecure? Am I that bad of a developer?”
As a developer, I hadn’t really come across such heavy security concepts before. Sure, I knew about authentication and basic access controls, but hearing terms like Cross-Site Scripting and SQL Injection thrown around like they were common knowledge was a whole new level. To be honest, it was intimidating and overwhelming— I didn’t understand half of what they were talking about. I had never really come across these heavy security concepts before. And suddenly, I realised there was a lot more to learn.
Instead of feeling defeated, I decided to turn it into a learning experience. I would sit next to the VAPT engineers, asking them what each issue meant and how I could fix it. I’d go back to my desk, Google each term (yep, this was before the days when we could just “ChatGPT” everything), and spend nights debugging my code, trying to make it secure enough to stand up to their scrutiny.
Slowly but surely, I started to understand what those vulnerabilities meant, why they mattered, and — most importantly — how to fix them. It wasn’t easy, but I knew that with every bug I squashed, I was making my app safer for our users.
And that’s exactly why I’m writing this guide — so that you don’t have to go through the same confusion and frustration I did. Whether you’re a seasoned developer or new to security concepts, I want to help you understand these vulnerabilities in a straightforward way and show you how to fix them in your Node.js applications. With practical examples, easy-to-digest explanations, and the right coding techniques, we’ll make sure that your apps are not just functional, but secure enough to withstand even the most rigorous VAPT review.
Ready to dive into the world of secure coding? Let’s make your Node.js applications bulletproof together! 🚀
What is VAPT?
Vulnerability Assessment and Penetration Testing (VAPT) is a process used to identify and fix security weaknesses in an application. It consists of two parts:
Vulnerability Assessment: A systematic review of the security holes present in your code.
Penetration Testing: Simulated attacks on your application to see how those vulnerabilities can be exploited in the real world.
Think of VAPT as a safety checkup for your code, exposing potential security flaws before an attacker does. It can be nerve-wracking, but it’s absolutely necessary to ensure your app is production-ready. In this guide, I’ll walk you through some of the most common vulnerabilities you might encounter and show you how to fix each one. Let’s secure that code, one bug at a time! 💡🔒
1. Injection Attacks (SQL, NoSQL)
Injection attacks, such as SQL or NoSQL injection, occur when an attacker sends input that is interpreted as part of the command by the database instead of as plain data. These attacks can result in unauthorised access, data breaches, and data corruption.
How It Affects Your System
An attacker might gain access to sensitive data, such as user credentials, by manipulating the input fields in your application to alter SQL or NoSQL queries. In more severe cases, SQL Injection can also be used to gain a foothold into the system, potentially leading to Remote Code Execution (RCE), where an attacker can execute arbitrary code on your server. This escalates the attack from simply accessing data to potentially taking full control of the system.
Must Watch - Understanding SQL Injection and RCE in Action
Example Scenario
Suppose your Node.js app allows users to search for books by category:
app.get('/books', (req, res) => {
const category = req.query.category;
const query = `SELECT * FROM books WHERE category = '${category}'`;
db.query(query, (err, results) => {
if (err) {
res.status(500).send('Error fetching data');
} else {
res.json(results);
}
});
});
If a user sends a request with the following URL:
https://api.example.com/books?category=science' OR '1'='1
The resulting query becomes:
SELECT * FROM books WHERE category = 'science' OR '1'='1';
This would return all books because the condition '1'='1' is always true. An attacker could further manipulate this to extract sensitive data.
Good Code Practice
app.get('/books', (req, res) => {
const category = req.query.category;
const query = 'SELECT * FROM books WHERE category = ?';
db.query(query, [category], (err, results) => {
if (err) {
res.status(500).send('Error fetching data');
} else {
res.json(results);
}
});
});
Why This Works
Parameterized queries ensure that user inputs are treated as values rather than part of the SQL syntax. This prevents attackers from altering the structure of the SQL statement.
2. Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) occurs when an attacker injects malicious JavaScript into your web application. This script then runs in the browser of any user who accesses the affected page, allowing attackers to steal cookies, session tokens, or other sensitive data.
How It Affects Your System
XSS can allow attackers to hijack user sessions, steal credentials, and even alter the appearance or behaviour of your web pages, significantly compromising user trust and data integrity.
Example Scenario
Consider a feature in your application where users can post text that is rendered on a page:
const userInput = "<script>alert('XSS!')</script>";
res.send(`User comment: ${userInput}`);
If user input is rendered directly, any JavaScript included by the attacker will execute when the page loads in a user’s browser.
Good Code Practice
const escape = require('escape-html');
const userInput = "<script>alert('XSS!')</script>";
res.send(`User comment: ${escape(userInput)}`);
Why This Works
Using a library like escape-html ensures that any HTML tags in user input are treated as plain text, preventing them from being executed as scripts.
3. Insecure Direct Object References (IDOR)
IDOR (Insecure Direct Object Reference) occurs when a user can access resources or objects directly by manipulating input values such as URL parameters without proper authorization checks. While this vulnerability is commonly found in URL parameters, it can also occur in other parts of a request, such as form inputs, headers, or cookies, wherever user input is used to directly reference resources without validation.
How It Affects Your System
IDOR can expose sensitive data to unauthorized users, such as accessing another user’s profile or viewing confidential documents.
Example Scenario
Imagine an endpoint where users can view their profile:
app.get('/profile/:userId', (req, res) => {
const userId = req.params.userId;
User.findById(userId, (err, user) => {
res.json(user);
});
});
An attacker could alter the userId parameter to access other users’ data:
https://api.example.com/profile/12345
Good Code Practice
app.get('/profile/:userId', (req, res) => {
const userId = req.params.userId;
if (req.user.id !== userId) {
return res.status(403).send('Access Denied');
}
User.findById(userId, (err, user) => {
res.json(user);
});
});
Why This Works
By checking that the authenticated user’s ID matches the requested userId, we ensure that users can only access their own data.
4. Denial-of-Service (DoS) Vulnerabilities
Denial-of-Service (DoS) attacks aim to overwhelm a server with a high volume of requests, consuming its resources like bandwidth, CPU, and memory, which makes the server unavailable to legitimate users. This can be particularly damaging to public APIs or services, leading to a degraded user experience due to downtime and potentially causing significant financial losses, such as disrupted services and lost revenue. Unlike standard DoS attacks that originate from a single source, Distributed Denial-of-Service (DDoS) attacks involve multiple systems, making them even harder to mitigate and more destructive. For example, an e-commerce website facing a DoS attack during peak shopping seasons might experience outages, resulting in lost sales and a tarnished reputation.
How It Affects Your System
DoS attacks can severely impact the performance and availability of your application. They may cause your server to slow down, making it difficult for legitimate users to access your services, or even render your application completely unresponsive. The increased load can exhaust server resources like memory, CPU, and network bandwidth, leading to system crashes or forced restarts. This kind of disruption can result in lost revenue, especially if your application is critical to business operations. Additionally, prolonged unavailability can damage your brand’s reputation, erode customer trust, and incur costs for mitigation and recovery.
a) Example Scenario: Missing Payload Size Limitation (Vulnerable to Large Payload Attack)
Consider an endpoint that processes large JSON payloads:
app.post('/data', (req, res) => {
const data = req.body;
res.send('Data processed');
});
An attacker could send an enormous payload, causing the server to run out of memory and crash.
Good Code Practice: Payload Size Limitation
const express = require('express');
const app = express();
app.use(express.json({ limit: '1mb' }));
app.post('/data', (req, res) => {
const data = req.body;
res.send('Data processed');
});
Why This Works
By setting a size limit for incoming JSON payloads, you prevent attackers from overwhelming your server with large requests.
b) Example Scenario: Missing Rate Limiting (Vulnerable to Request Flood Attack)
Another way DoS attacks can occur is when your server is overwhelmed with requests from multiple sources without proper rate limiting. An attacker could flood the endpoint with requests, which may crash the server or significantly slow down its performance.
Good Code Practice: Adding Rate Limit
const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
windowMs: 1 * 60 * 1000,
max: 100,
});
app.use(limiter);
app.post('/data', (req, res) => {
const data = req.body;
res.send('Data processed');
});
Why This Works
Rate limiting helps mitigate excessive requests from a single source, preserving server resources and maintaining application availability. By implementing this measure, you ensure that legitimate users can access the service without interruption.
c) Example Scenario: Vulnerable to Regular Expression Denial of Service (ReDoS)
A ReDoS attack exploits the fact that certain regular expressions can take an exponential amount of time to evaluate when applied to maliciously crafted input, effectively causing the system to hang or enter a "pause" mode. This is particularly dangerous if the regex is used for input validation in an API that accepts user input.
const regex = /^(a+)+$/;
app.post('/validate', (req, res) => {
const { input } = req.body;
if (regex.test(input)) {
res.send('Valid input');
} else {
res.send('Invalid input');
}
});
An attacker could submit a string like "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!", which can cause the regex engine to backtrack excessively, resulting in high CPU usage and making the server unresponsive.
Good Code Practice: Using Safe Regular Expressions
const safeRegex = /^a{1,100}$/;
app.post('/validate', (req, res) => {
const { input } = req.body;
if (input.length > 100) {
return res.status(400).send('Input too long');
}
if (safeRegex.test(input)) {
res.send('Valid input');
} else {
res.send('Invalid input');
}
});
Why This Works
By using safer regex patterns or limiting input length, you can avoid the risk of excessive backtracking that can lead to ReDoS attacks. This keeps the server responsive and protects against unexpected resource exhaustion.
5. Improper Authentication and Authorization
Improper Authentication and Authorization occur when an application does not correctly verify the identity of users or their permissions.
How It Affects Your System
Weak authentication mechanisms can lead to unauthorized access, allowing malicious users to exploit sensitive areas of your application. This can result in data breaches, unauthorized data manipulation, and overall compromise of user trust.
Example Scenario
Consider a login endpoint:
const token = req.headers['authorization'];
if (token === '12345') {
}
This approach allows anyone who knows the token to gain access or any attacker who is able to brute-force it. The predictability of the token ('12345') means that an attacker can easily guess or automate attempts to gain access, leading to serious security vulnerabilities.
Brute-forcing the token is alarmingly simple. Given that the token is a short numeric string, an attacker could employ a basic script to iterate through all possible combinations (e.g., from 00000 to 99999). This would require only a few seconds or minutes, depending on the attacker's hardware and the implementation of any rate-limiting or lockout mechanisms in the application.
Good Code Practice
const jwt = require('jsonwebtoken');
require('dotenv').config();
const secretKey = process.env.SECRET_KEY;
function verifyToken(req, res, next) {
const token = req.headers['authorization'];
if (!token) return res.status(403).send('Forbidden');
jwt.verify(token, secretKey, (err, decoded) => {
if (err) return res.status(403).send('Invalid token');
req.user = decoded;
next();
});
}
app.get('/protected', verifyToken, (req, res) => {
res.send(`Welcome user with ID: ${req.user.id}`);
});
Why This Works
Using JSON Web Tokens (JWTs) [jsonwebtoken] provides a secure and verifiable method of authenticating users because they encapsulate all necessary user information in a self-contained format. JWTs are signed, ensuring integrity and authenticity, which prevents tampering. They also support expiration times, limiting access duration and reducing security risks. Additionally, JWTs can carry custom claims for flexible role-based access control and are suitable for cross-domain applications. This combination of features enables efficient, stateless authentication while ensuring that only authorized users can access protected resources.
6. Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is an attack that tricks a user into executing unwanted actions on a web application where they are authenticated. The attack relies on the victim’s browser being tricked into sending a request to the web application using the victim’s active session or credentials.
How It Affects Your System
CSRF attacks can result in unauthorized actions being performed on behalf of authenticated users. This can include actions like changing account settings, making transactions, or even stealing sensitive information by tricking the user into making requests they never intended to.
Example Scenario
Imagine a banking application where a user can transfer funds by visiting a specific URL:
<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="to" value="attacker_account">
<button type="submit">Transfer</button>
</form>
An attacker could trick a user into submitting this form by embedding a malicious element on their own website. The attacker’s malicious page could contain the following HTML:
<img src="https://bank.com/transfer?amount=1000&to=attacker_account" style="display:none">
If the victim is logged into their banking application, simply visiting the attacker’s page will trigger this hidden request, resulting in the transfer of funds without the user’s consent. This attack is possible if the banking application incorrectly accepts GET requests for state-changing actions, such as transferring funds.
Good Code Practice
To protect against CSRF attacks, you can implement anti-CSRF tokens. This involves adding a token to forms and validating it on the server side:
const csrfToken = generateCsrfToken();
res.send(`
<form action="/transfer" method="POST">
<!-- Use POST for state changes -->
<input type="hidden" name="csrf_token" value="${csrfToken}">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="to" value="attacker_account">
<button type="submit">Transfer</button>
</form>
`);
On the server side, verify the CSRF token before processing the request:
app.post('/transfer', (req, res) => {
const { csrf_token } = req.body;
if (!isValidCsrfToken(csrf_token)) {
return res.status(403).send('Invalid CSRF token');
}
});
Why This Works
By requiring a valid CSRF token for state-changing requests, you ensure that only legitimate requests originating from your application can be processed. Additionally, using POST instead of GET for state changes is crucial, as it prevents attackers from triggering unintended actions through simple image tags or links. Leveraging frameworks with built-in CSRF token protection (using tokens in headers or as POST parameters) further enhances security against CSRF attacks.
Additional Mitigation Tips
Use POST for State-Changing Requests: Ensure that any action that modifies data (like transfers or account changes) only accepts POST requests. GET requests should be reserved for retrieving data, not for making changes.
Implement SameSite Cookies: Setting the SameSite attribute on cookies can help to prevent them from being sent with cross-site requests, reducing the risk of CSRF.
Verify the Origin or Referer Headers: As an additional layer, check the Origin or Referer headers to ensure that the request comes from your domain.
7. Using eval()
The eval() function executes a string of JavaScript code in the context of the current execution environment. If user input is passed to eval() without proper validation, it can lead to serious security vulnerabilities.
How It Affects Your System
Using eval() with untrusted data can allow attackers to execute arbitrary code, potentially compromising the entire application.
Example Scenario
const userInput = "2 + 2";
const result = eval(userInput);
console.log(result);
If an attacker provides input like alert('Hacked!'), it will execute that code, leading to unwanted behavior.
Good Code Practice
Instead of using eval(), consider safer alternatives like Function constructor or libraries designed for evaluating mathematical expressions:
NOTE: Although the Function constructor is sometimes suggested, it is not recommended for production code due to similar risks.
const safeEval = (input) => {
if (/^[0-9+\-*\/\s()]*$/.test(input)) {
return new Function(`return ${input}`)();
} else {
throw new Error('Unsafe input detected');
}
};
const result = safeEval("2 + 2");
console.log(result);
Why This Works
Using the Function constructor is still risky and is categorized as Direct Dynamic Code Evaluation, which can lead to eval Injection attacks if user input is not strictly validated. Although it limits the scope of execution compared to eval(), it can still allow the execution of arbitrary code if misused.
8. Loose Comparisons (Type Juggling)
Using loose equality comparisons (==) instead of strict equality (===) can lead to unexpected behaviour in your application. This is often referred to as type juggling, where JavaScript automatically converts one or both operands to a common type before performing the comparison. Type juggling can be exploited in attacks, leading to security vulnerabilities.
How It Affects Your System
Loose comparisons may allow for type coercion, leading to bugs and potential security vulnerabilities if unexpected types are compared.
console.log(0 == '0');
console.log(false == '0');
console.log(null == undefined);
Example Scenario
const userRole = 'admin';
if (userRole == 'admin') {
console.log('Access granted');
} else {
console.log('Access denied');
}
const manipulatedRole = '0';
if (manipulatedRole == false) {
console.log('Access granted');
} else {
console.log('Access denied');
}
This can lead to situations where unexpected input is considered valid due to type coercion.
Good Code Practice
const userRole = 'admin';
if (userRole === 'admin') {
console.log('Access granted');
} else {
console.log('Access denied');
}
const manipulatedRole = '0';
if (manipulatedRole === false) {
console.log('Access granted');
} else {
console.log('Access denied');
}
Why This Works
Strict comparisons ensure that both the type and value must match, preventing unexpected type coercion.
9. Unvalidated Redirects and Forwards
Unvalidated redirects and forwards occur when an application allows users to redirect to external URLs or forward to other internal resources without proper validation. This can lead to security vulnerabilities where attackers can exploit these features to redirect users to malicious sites or perform unwanted actions within the application. This vulnerability is also known as open redirection.
How It Affects Your System
Unvalidated redirects and forwards can expose your users to various risks, such as phishing and malware attacks. When users are redirected to untrusted or malicious sites, they may unknowingly provide sensitive information to attackers, believing they are interacting with your legitimate application. This can result in identity theft, loss of credentials, and unauthorized access to user accounts. Furthermore, if your application is exploited to facilitate such attacks, it can harm your reputation and user trust, leading to a decline in user engagement and potential legal repercussions.
In addition, internal forwards without validation can allow attackers to access restricted areas within your application or bypass authorization checks. This could lead to data breaches or unauthorized actions within your application, making it crucial to validate redirect and forward requests properly.
Example Scenario
app.get('/redirect', (req, res) => {
const redirectUrl = req.query.url;
res.redirect(redirectUrl);
});
If a user clicks on a link like https://yourapp.com/redirect?url=https://malicious-site.com, they will be redirected to a malicious site, potentially exposing them to phishing attacks or malware.
Good Code Practice
To mitigate this risk, it is essential to validate the redirect URL. Moreover, you should ensure that all allowed URLs use HTTPS to prevent downgrade attacks.
const allowedUrls = ['https://trusted.com'];
app.get('/redirect', (req, res) => {
const url = req.query.url;
if (!allowedUrls.includes(url)) {
return res.status(400).send('Invalid URL');
}
if (!url.startsWith('https://')) {
return res.status(400).send('URL must use HTTPS');
}
res.redirect(url);
});
Why This Works
Validating the redirect URL prevents attackers from redirecting users to malicious sites. By maintaining a whitelist of allowed URLs, you ensure that users can only be redirected to trusted locations, mitigating the risk of phishing and other attacks that exploit unvalidated redirects and forwards.
10. File Upload Exploit
File upload vulnerabilities occur when an application allows users to upload files without proper validation or restrictions. This can lead to malicious files being uploaded and executed on the server, potentially leading to data breaches or server compromise.
How It Affects Your System
Attackers can exploit insecure file upload functionality to upload malicious scripts or executables that can be run on the server, gaining unauthorized access or control over the system.
Example Scenario
Consider a web application that allows users to upload profile pictures:
app.post('/upload', (req, res) => {
const file = req.files.picture;
file.mv(`./uploads/${file.name}`, (err) => {
if (err) return res.status(500).send(err);
res.send('File uploaded!');
});
});
In this scenario, an attacker could upload a malicious PHP file (e.g., malicious.php) and execute it by accessing it directly:
http://example.com/uploads/malicious.php
Good Code Practice
To mitigate the risks associated with file uploads, implement the following best practices:
File Type Validation: Check the file extension and MIME type against a whitelist of allowed types.
Magic Header Bytes Check: In addition to MIME type validation, verify the file's magic header bytes to ensure it matches the expected format.
Limit File Size: Set restrictions on the maximum file size to prevent abuse.
Rename Uploaded Files: Rename files upon upload to avoid execution of malicious code and prevent filename conflicts.
Store Files Outside the Web Root: Save uploaded files in a directory that is not publicly accessible to prevent direct access.
const fs = require('fs');
const path = require('path');
app.post('/upload', (req, res) => {
const file = req.files.picture;
const validTypes = ['image/jpeg', 'image/png', 'image/gif'];
if (!validTypes.includes(file.mimetype)) {
return res.status(400).send('Invalid file type');
}
const magicBytes = {
'image/jpeg': Buffer.from([0xff, 0xd8, 0xff]),
'image/png': Buffer.from([0x89, 0x50, 0x4e, 0x47]),
'image/gif': Buffer.from([0x47, 0x49, 0x46]),
};
const fileBuffer = fs.readFileSync(file.tempFilePath);
const fileMagic = fileBuffer.slice(0, magicBytes[file.mimetype].length);
if (!fileMagic.equals(magicBytes[file.mimetype])) {
return res.status(400).send('Invalid file content');
}
const maxSize = 1 * 1024 * 1024;
if (file.size > maxSize) {
return res.status(400).send('File too large');
}
const originalFileName = path.basename(file.name, path.extname(file.name));
const sanitizedBaseName = originalFileName.replace(/[^a-zA-Z0-9_-]/g, '');
const timestamp = Date.now();
const safeFileName = `${sanitizedBaseName}_${timestamp}${path.extname(file.name)}`;
const uploadPath = path.join(__dirname, 'uploads', safeFileName);
file.mv(uploadPath, (err) => {
if (err) return res.status(500).send(err);
res.send('File uploaded!');
});
});
Why This Works
By validating file types, checking magic header bytes, limiting file sizes, renaming uploaded files, and storing them outside of the web root, you significantly reduce the risk of file upload vulnerabilities. These practices enhance the overall security of your application by ensuring that only safe files are accepted and executed.
Additional Mitigation Tips
Ensure Folder Permissions: Configure the upload folder with chmod settings that do not allow execution (e.g., chmod 644 for files).
Magic Header Bytes Limitations: Be aware that magic header bytes checking can be bypassed if attackers manipulate the byte headers. Always combine this with other validation methods like server-side MIME type checks.
Client-Side & Server-Side Validation: Validate the file's MIME type on both the client and server-side to ensure it matches the expected format. However, do not rely solely on client-side validation, as it can be manipulated by attackers.
Conclusion
As we wrap up this journey through the various security vulnerabilities and their mitigations, I want to emphasize the importance of adopting a proactive mindset towards securing coding practices. Each vulnerability we’ve explored, from SQL Injection to File Upload Exploits, represents not just a potential risk, but an opportunity for us as developers to fortify our applications and protect our users.
The world of security may seem daunting, but it’s essential to remember that every developer starts somewhere. Just as I faced my initial challenges with secure coding during VAPT reviews, you too can transform your approach to coding security. By understanding these vulnerabilities and implementing the recommended best practices, you’re not just fixing issues — you’re building a robust foundation for your applications.
The tools and techniques we’ve discussed are here to help you create secure, resilient code that can stand up to scrutiny and keep your users safe. Embrace the learning process, ask questions, and continually seek to enhance your understanding of secure coding practices. With every vulnerability you address, you’re making your software more trustworthy, ensuring a better experience for everyone who interacts with it.
Thank you for taking the time to read this guide. I hope it empowers you to become a more security-conscious developer, turning challenges into stepping stones for growth. Together, let’s strive to make the web a safer place, one line of code at a time. Happy coding! 🛡️✨
![[EXPERT] Reflected XSS with AngularJS sandbox escape without strings](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F66f6453769132feb8ba076b0%2F111ea636-bcfe-491b-b495-b6549d0ebcfe.png&w=3840&q=75)
![Lecture 4 - Rediscovering Process Scheduling [Part - 1]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1765604682888%2F80e6cf20-aded-4aac-8c75-affdd35615b2.jpeg&w=3840&q=75)