Filename: routes/dataErasure.ts:69
Allowing unsanitized user input in path resolution methods means an attacker could gain access to files and folders outside of the intended scope.
❌ Avoid wherever possible
✅ Sanitize user input when resolving paths, for example:
- Use replace() to mitigate against unwanted patterns in the path (such as \..\..)
- Actively guard against paths that end in “%00” (poison NULL byte attacks)
- Use path concatenation to ensure the intended scope is respected
const path = require("path");
app.get("/", (req, res) => {
if (req.params.path.indexOf('\0')) !== -1 {
// prevent access
}
var folder = req.params.path.replace(/^(\.\.(\/|\\|$))+/, '')
var pathname = path.join("/public/", folder)
if pathname.indexOf("/public/") !== 0 {
// prevent access
}
path.resolve(pathname)
})
Filename: routes/keyServer.ts:14
Allowing unsanitized user input in path resolution methods means an attacker could gain access to files and folders outside of the intended scope.
❌ Avoid wherever possible
✅ Sanitize user input when resolving paths, for example:
- Use replace() to mitigate against unwanted patterns in the path (such as \..\..)
- Actively guard against paths that end in “%00” (poison NULL byte attacks)
- Use path concatenation to ensure the intended scope is respected
const path = require("path");
app.get("/", (req, res) => {
if (req.params.path.indexOf('\0')) !== -1 {
// prevent access
}
var folder = req.params.path.replace(/^(\.\.(\/|\\|$))+/, '')
var pathname = path.join("/public/", folder)
if pathname.indexOf("/public/") !== 0 {
// prevent access
}
path.resolve(pathname)
})
Filename: routes/logfileServer.ts:14
Allowing unsanitized user input in path resolution methods means an attacker could gain access to files and folders outside of the intended scope.
❌ Avoid wherever possible
✅ Sanitize user input when resolving paths, for example:
- Use replace() to mitigate against unwanted patterns in the path (such as \..\..)
- Actively guard against paths that end in “%00” (poison NULL byte attacks)
- Use path concatenation to ensure the intended scope is respected
const path = require("path");
app.get("/", (req, res) => {
if (req.params.path.indexOf('\0')) !== -1 {
// prevent access
}
var folder = req.params.path.replace(/^(\.\.(\/|\\|$))+/, '')
var pathname = path.join("/public/", folder)
if pathname.indexOf("/public/") !== 0 {
// prevent access
}
path.resolve(pathname)
})
Filename: routes/quarantineServer.ts:14
Allowing unsanitized user input in path resolution methods means an attacker could gain access to files and folders outside of the intended scope.
❌ Avoid wherever possible
✅ Sanitize user input when resolving paths, for example:
- Use replace() to mitigate against unwanted patterns in the path (such as \..\..)
- Actively guard against paths that end in “%00” (poison NULL byte attacks)
- Use path concatenation to ensure the intended scope is respected
const path = require("path");
app.get("/", (req, res) => {
if (req.params.path.indexOf('\0')) !== -1 {
// prevent access
}
var folder = req.params.path.replace(/^(\.\.(\/|\\|$))+/, '')
var pathname = path.join("/public/", folder)
if pathname.indexOf("/public/") !== 0 {
// prevent access
}
path.resolve(pathname)
})
Filename: lib/insecurity.ts:43
Code is not a safe place to store secrets, use environment variables instead.
passport.use(new OAuth2Strategy({
authorizationURL: 'https://www.example.com/oauth2/authorize',
tokenURL: 'https://www.example.com/oauth2/token',
clientID: process.env.CLIENT_ID,
clientSecret: process.env.CLIENT_SECRET,
callbackURL: "http://localhost:3000/auth/example/callback"
},
function(accessToken, refreshToken, profile, cb) {
User.findOrCreate({ exampleId: profile.id }, function (err, user) {
return cb(err, user);
});
}
));
Filename: lib/insecurity.ts:166
Code is not a safe place to store secrets, use environment variables instead.
passport.use(new OAuth2Strategy({
authorizationURL: 'https://www.example.com/oauth2/authorize',
tokenURL: 'https://www.example.com/oauth2/token',
clientID: process.env.CLIENT_ID,
clientSecret: process.env.CLIENT_SECRET,
callbackURL: "http://localhost:3000/auth/example/callback"
},
function(accessToken, refreshToken, profile, cb) {
User.findOrCreate({ exampleId: profile.id }, function (err, user) {
return cb(err, user);
});
}
));
Filename: routes/profileImageUrlUpload.ts:22
Applications should not connect to locations formed from user input. This rule checks for URLs containing user-supplied data.
❌ Avoid using user input in HTTP URLs:
const response = axios.get(`https://${req.params.host}`)
✅ Use user input indirectly to form a URL:
const hosts = new Map([
["option1", "api1.com"],
["option2", "api2.com"]
])
const host = hosts.get(req.params.host)
const response = axois.get(`https://${host}`)
Filename: lib/insecurity.ts:55
Code is not a secure place to store secrets, use environment variables instead.
Use environment variables
var jwt = require("jsonwebtoken");
var token = jwt.sign({ foo: "bar" }, process.env.JWT_SECRET);
Filename: frontend/src/app/login/login.component.ts:102
Sensitive data should not be stored in a localStorage session. This policy looks for any sensitive data stored within the localstorage.
It’s best to avoid storing sensitive data in localStorage whenever possible. To keep session data safe, use a server-based session storage solution instead.
❌ If you do need do store data in localStorage, avoid including sensitive data:
localStorage.setItem('user', email)
✅ Instead, use a unique identifier:
localStorage.setItem('user', user.uuid)
Filename: data/static/codefixes/dbSchemaChallenge_1.ts:5
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/dbSchemaChallenge_3.ts:11
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/loginAdminChallenge_1.ts:20
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/loginBenderChallenge_1.ts:20
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/loginBenderChallenge_4.ts:17
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/loginJimChallenge_2.ts:17
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/loginJimChallenge_4.ts:20
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/unionSqlInjectionChallenge_1.ts:6
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/unionSqlInjectionChallenge_3.ts:10
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: routes/login.ts:36
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: routes/search.ts:23
Including unsanitized data, such as user input or request data, in raw SQL queries makes your application vulnerable to SQL injection attacks.
❌ Avoid raw queries, especially those that contain unsanitized user input
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query("SELECT * FROM users WHERE ID = " + req.params.userId);
Instead, consider the following approaches when writing SQL queries
✅ Validate query input wherever possible
var rawId = req.params.userId
if !(/[0-9]+/.test(rawId)) {
// input is unexpected; don't make the query
}
✅ Use prepared (or parameterized) statements when querying
Sequelize example -
var sqlite = new Sequelize("sqlite::memory:");
sqlite.query(
"SELECT * FROM users WHERE ID = ?",
{ replacements: [req.params.userId] },
type: sequelize.QueryTypes.SELECT
)
Filename: data/static/codefixes/accessLogDisclosureChallenge_1_correct.ts:2
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_1_correct.ts:7
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_2.ts:2
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_2.ts:7
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_2.ts:11
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_3.ts:2
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_3.ts:7
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_3.ts:11
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_4.ts:2
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/accessLogDisclosureChallenge_4.ts:7
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_1_correct.ts:2
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_1_correct.ts:6
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_2.ts:6
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_2.ts:10
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_3.ts:2
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_3.ts:5
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_3.ts:9
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_4.ts:2
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_4.ts:7
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: data/static/codefixes/directoryListingChallenge_4.ts:11
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: server.ts:241
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: server.ts:246
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: server.ts:250
Inappropriate exposure of a directory listing could give attackers access to sensitive data or source code, either directly or through exploitation of an exposed file structure.
✅ Restrict access to sensitive directories and files
Filename: routes/keyServer.ts:14
Passing unsanitized user input to the sendFile API is bad practice and can lead to path manipulation, by which attackers can gain access to resources and data outside of the intended scope.
✅ Set the root option to be an absolute path to a directory
app.post("/upload", (req, res) => {
var options = {
root: path.join(__dirname, "upload")
}
res.sendFile(req.params.filename, options)
}
Filename: routes/logfileServer.ts:14
Passing unsanitized user input to the sendFile API is bad practice and can lead to path manipulation, by which attackers can gain access to resources and data outside of the intended scope.
✅ Set the root option to be an absolute path to a directory
app.post("/upload", (req, res) => {
var options = {
root: path.join(__dirname, "upload")
}
res.sendFile(req.params.filename, options)
}
Filename: routes/quarantineServer.ts:14
Passing unsanitized user input to the sendFile API is bad practice and can lead to path manipulation, by which attackers can gain access to resources and data outside of the intended scope.
✅ Set the root option to be an absolute path to a directory
app.post("/upload", (req, res) => {
var options = {
root: path.join(__dirname, "upload")
}
res.sendFile(req.params.filename, options)
}
Filename: lib/insecurity.ts:53
The best practice caching policy is to revoke JWTs especially when these contain senstitive information.
✅ Ensure JWTs are short-lived by revoking them
expressjwt({
...
isRevoked: this.customRevokeCall(),
...
})
Filename: lib/insecurity.ts:54
The best practice caching policy is to revoke JWTs especially when these contain senstitive information.
✅ Ensure JWTs are short-lived by revoking them
expressjwt({
...
isRevoked: this.customRevokeCall(),
...
})
Filename: data/static/codefixes/redirectChallenge_3.ts:22
Sanitizing HTML manually is error prone and can lead to Cross Site Scripting (XSS) vulnerabilities.
❌ Avoid manually escaping HTML:
const sanitizedUserInput = user.Input
.replaceAll('<', '<')
.replaceAll('>', '>');
const html = `<strong>${sanitizedUserInput}</strong>`;
✅ Use a HTML sanitization library:
import sanitizeHtml from 'sanitize-html';
const html = sanitizeHtml(`<strong>${user.Input}</strong>`);
Filename: data/static/codefixes/restfulXssChallenge_2.ts:59
Sanitizing HTML manually is error prone and can lead to Cross Site Scripting (XSS) vulnerabilities.
❌ Avoid manually escaping HTML:
const sanitizedUserInput = user.Input
.replaceAll('<', '<')
.replaceAll('>', '>');
const html = `<strong>${sanitizedUserInput}</strong>`;
✅ Use a HTML sanitization library:
import sanitizeHtml from 'sanitize-html';
const html = sanitizeHtml(`<strong>${user.Input}</strong>`);
Filename: Gruntfile.js:74
Sensitive data should be encrypted with strong encryption algorithms like aes-256-cbc
According to OWASP: MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80⁄112-bit 2TDEA (two key triple DES) are considered as weak hash/encryption algorithms and therefore shouldn’t be used.
✅ Use stronger encryption algorithms when storing data.
const crypto = require("crypto");
const key = "secret key";
const encrypted = crypto.createHmac("es-256-cbc", key).update(user.password);
Filename: lib/insecurity.ts:42
Sensitive data should be encrypted with strong encryption algorithms like aes-256-cbc
According to OWASP: MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80⁄112-bit 2TDEA (two key triple DES) are considered as weak hash/encryption algorithms and therefore shouldn’t be used.
✅ Use stronger encryption algorithms when storing data.
const crypto = require("crypto");
const key = "secret key";
const encrypted = crypto.createHmac("es-256-cbc", key).update(user.password);