10 Essential JavaScript Best Practices for Modern Web Dev

POST-MORTEM INCIDENT #8842-OMEGA
TIMESTAMP: 2024-05-22T04:12:09Z
STATUS: CRITICAL / SYSTEM COMPROMISED
ANALYST: Senior Forensic Auditor (ID: 0xDEADBEEF)
SUBJECT: THE ANATOMY OF A CATASTROPHIC FAILURE

---

1. THE SMOKING GUN: EXPLOIT LOG

I’ve been staring at this buffer for fourteen hours. The coffee is cold, the fluorescent lights are humming at a frequency that makes my teeth ache, and your code is a crime scene. You thought you were building a “modern” microservice. What you actually built was a glass house in a neighborhood full of brick-throwers.

Here is how they got in. They didn’t use a sophisticated zero-day. They used your own incompetence.

# STACK TRACE RECOVERY - NODE_V21.6.2 - PID 4401
$ curl -X POST https://api.internal.production/v1/settings \
  -H "Content-Type: application/json" \
  -d '{"__proto__": {"polluted": "yes", "shell": "/bin/sh", "NODE_OPTIONS": "--inspect=0.0.0.0:9229"}}'

# RESPONSE: 200 OK (The sound of the gallows closing)

$ curl -X GET https://api.internal.production/v1/status
# INTERNAL LOGS SHOWING THE PAYLOAD EXECUTION:
# [DEBUG] Object.prototype.polluted = "yes"
# [ERROR] Uncaught ReferenceError: process is not defined (Triggering V8 Crash)
# [INFO] V8 Inspector opened on 0.0.0.0:9229
# [CRITICAL] Remote Debugger Attached. Memory Dump Initiated.
# [CRITICAL] Exfiltrating /etc/shadow...
# [CRITICAL] Exfiltrating K8S_SECRET_TOKEN...

The attacker didn’t even have to try. They polluted the global object prototype using a recursive merge function in an outdated utility library you refused to update because “it might break the build.” Well, the build is broken now. The whole company is broken.

---

2. THE GRIEVANCE LIST: WHY WE ARE HERE

Before I give you the “javascript best” practices that might save your jobs, you need to understand the depth of your failure. I’ve cataloged the reasons this system collapsed:

• Dependency Fetishism: You have 1,400 dependencies in your package-lock.json. You are running code written by strangers who don’t care about your uptime.
• Prototype Blindness: You treat JavaScript objects like simple dictionaries. They aren’t. They are complex, linked structures with a hidden inheritance chain that can be weaponized.
• Event Loop Negligence: You’re performing heavy cryptographic operations and massive JSON parsing on the main thread. You’ve turned our high-throughput server into a glorified calculator that freezes when it sees a large string.
• The “It Works on My Machine” Fallacy: You ignored the Node.js 21.6.2 security releases. You ignored the Permission Model. You ran the process as root.
• Silent Failures: You wrapped everything in try-catch blocks that swallow errors and return null. You didn’t handle the error; you hid the body.

---

THE FALLACY OF TRUSTING YOUR DEPENDENCIES

You are running Express 4.18.2 and Lodash 4.17.21. You think because they are popular, they are safe. Lodash 4.17.21 is a ticking time bomb for prototype pollution if you aren’t careful with how you handle user-supplied keys.

When we talk about javascript best practices, we aren’t talking about aesthetics; we are talking about survival. In the breach, the attacker sent a JSON payload that targeted a recursive merge() call. Because you didn’t validate the keys, the V8 engine happily assigned the property to the global Object.prototype.

THE VULNERABILITY (BEFORE):

// Express 4.18.2 Route - Vulnerable to Prototype Pollution
const _ = require('lodash'); // v4.17.21
const express = require('express');
const app = express();

app.use(express.json());

app.post('/v1/settings', (req, res) => {
    const userSettings = req.body;
    const defaultSettings = { theme: 'dark', notifications: true };

    // FATAL ERROR: Recursive merge on untrusted input
    const finalSettings = _.merge(defaultSettings, userSettings);
    res.status(200).send(finalSettings);
});

THE HARDENED DEFENSE (AFTER):
In Node.js 21.6.2, we have better ways. We use Object.create(null) to ensure our objects don’t have a prototype to pollute, and we use the built-in Object.freeze to lock down our configuration.

// Hardened implementation using Node 21.6.2 standards
const express = require('express');
const app = express();

app.use(express.json({ limit: '1kb' })); // Limit payload size to prevent DoS

app.post('/v1/settings', (req, res) => {
    // javascript best practice: Create a prototype-less object
    const safeSettings = Object.create(null);
    Object.assign(safeSettings, { theme: 'dark', notifications: true });

    const untrustedInput = req.body;

    // Defensive check: Block reserved keys
    const forbiddenKeys = ['__proto__', 'constructor', 'prototype'];
    for (const key of Object.keys(untrustedInput)) {
        if (forbiddenKeys.includes(key)) {
            console.error(`[SECURITY ALERT] Attempted prototype pollution on key: ${key}`);
            return res.status(400).send('Invalid input');
        }
        safeSettings[key] = untrustedInput[key];
    }

    Object.freeze(safeSettings); // Prevent further modification
    res.status(200).send(safeSettings);
});

---

MEMORY LEAKS: THE SLOW DEATH OF THE EVENT LOOP

During my 72-hour hell-dive, I found a memory leak that was consuming 150MB of heap every hour. By the time the server crashed, the V8 garbage collector was spending 90% of the CPU time trying to reclaim memory that was still being referenced by a “simple” logging closure.

Look at this heapdump analysis. This is what your “quick fix” looks like at the byte level.

# HEAPDUMP ANALYSIS - PID 4401 - 2024-05-21
# Total Heap Size: 1.8GB
# Top Consumers:
# (string) : 1.2GB - "User Session Data: { ... }"
# (closure) : 400MB - anonymous function at logger.js:45
# (array) : 150MB - globalRequestLogStack

# V8 Statistics:
# malloc_memory: 2,048,122,880 bytes
# peak_malloced_memory: 2,516,582,400 bytes
# does_zap_garbage: 0

You were pushing every request object into a global array for “analytics” and never clearing it. In Node.js, the garbage collector cannot reclaim memory if a reference still exists in a reachable scope. You created a permanent reference to every user who visited the site.

THE VULNERABILITY (BEFORE):

const requestLogs = []; // Global scope - NEVER DO THIS

app.use((req, res, next) => {
    requestLogs.push(req); // Keeps the entire req object (and its headers, sockets) in memory
    next();
});

THE HARDENED DEFENSE (AFTER):
Use WeakMap or WeakSet if you must associate data with objects, or better yet, use a capped buffer or a dedicated logging stream that doesn’t hold references in the V8 heap.

// javascript best practice: Use streams and avoid global state
const fs = require('node:fs');
const logStream = fs.createWriteStream('./access.log', { flags: 'a' });

app.use((req, res, next) => {
    const logEntry = {
        time: Date.now(),
        method: req.method,
        path: req.path,
        ip: req.ip
    };

    // Write to stream, don't store in memory
    logStream.write(JSON.stringify(logEntry) + '\n');
    next();
});

---

THE PERMISSION MODEL: YOUR ONLY REMAINING SHIELD

You ran the production server with full access to the file system. Why? Why does a REST API need to be able to execute rm -rf /? Node.js 21.6.2 has a built-in Permission Model. If you had used it, the attacker’s attempt to read /etc/shadow would have been killed by the runtime.

THE VULNERABILITY (BEFORE):

# How you ran the app
node server.js

THE HARDENED DEFENSE (AFTER):
You must restrict the process at the runtime level. Use the --experimental-permission flag. This isn’t optional anymore. It is a javascript best practice for anyone who doesn’t want to be featured on the front page of Krebs on Security.

# How you SHOULD have run the app
node --experimental-permission \
     --allow-fs-read=/home/node/app/static \
     --allow-fs-write=/home/node/app/logs \
     --allow-net=api.external-service.com \
     server.js

If the code tries to access anything outside those paths, Node.js throws a ERR_ACCESS_DENIED. It’s that simple. But you were too lazy to define your boundaries.

---

THE PROTOTYPE CHAIN IS A LOADED GUN

I found eval() in your codebase. I found new Function(). You said you needed it for “dynamic template rendering.” I say you provided a loaded gun to the attacker and pointed it at your own head.

In Node.js 21.6.2, the V8 engine optimizes code based on “hidden classes.” When you use eval(), you break these optimizations, forcing the engine into a slow path. But more importantly, you allow for arbitrary code execution.

THE VULNERABILITY (BEFORE):

// Vulnerable dynamic key access
function getValue(obj, path) {
    return eval(`obj.${path}`); // If path is "constructor.prototype.foo = 'bar'", you're dead.
}

THE HARDENED DEFENSE (AFTER):
Never, under any circumstances, use eval(). Use a strict allow-list and direct property access.

// javascript best practice: Strict property resolution
function getSafeValue(obj, path) {
    const parts = path.split('.');
    let current = obj;

    for (const part of parts) {
        if (part === '__proto__' || part === 'constructor') {
            throw new Error('Security Violation: Prototype access detected');
        }
        current = current[part];
        if (current === undefined) return undefined;
    }
    return current;
}

---

TEMPORAL SANITY VS. DATE-BASED CHAOS

The attacker used a timing attack to enumerate valid user IDs. Your use of the legacy Date object for checking session expiration was inconsistent. The Date object is notorious for being affected by system clock shifts and leap seconds, making it a poor choice for high-precision security checks.

Node.js 21.6.2 supports the Temporal API (via polyfill or experimental flags). It provides nanosecond precision and is monotonic, meaning it doesn’t go backward.

THE VULNERABILITY (BEFORE):

const startTime = Date.now();
// ... perform sensitive check ...
const endTime = Date.now();
if (endTime - startTime < 100) {
    // Potential timing attack vulnerability
}

THE HARDENED DEFENSE (AFTER):
Use process.hrtime.bigint() for precision or the Temporal API for wall-clock time that is resistant to system clock manipulation.

// javascript best practice: High-resolution monotonic timers
const start = process.hrtime.bigint();

// Perform check
const end = process.hrtime.bigint();
const duration = end - start;

// Use a constant-time comparison to prevent side-channel leaks
const crypto = require('node:crypto');
const isValid = crypto.timingSafeEqual(bufferA, bufferB);

---

SERIALIZATION IS WHERE DATA GOES TO DIE

The final nail in the coffin was your handling of JSON.parse. You assumed that if it was valid JSON, it was safe data. It isn’t. An attacker can send a JSON object with 10,000 nested arrays, causing a “Billion Laughs” style DoS attack on the V8 parser, or they can send duplicate keys to see how your specific parser handles them.

RAW TERMINAL OUTPUT: NPM AUDIT

$ npm audit
# npm audit report

lodash  <4.17.21
Severity: critical
Prototype Pollution in lodash - https://github.com/advisories/GHSA-p6mc-m476-83be
No fix available. (Wait, you didn't even check?)

qs  <6.5.3
Severity: high
qs vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-hrpp-h998-j3pp

Found 12 vulnerabilities in 1402 packages.
Run `npm audit fix` to NOT fix them because you have breaking changes.

You ignored the audit. You ignored the warnings. You let the “javascript best” practices rot while you chased new features.

THE HARDENED DEFENSE (AFTER):
Use a schema validator like Ajv with strict mode enabled. Never trust the structure of a JSON object just because it parsed correctly.

const Ajv = require('ajv');
const ajv = new Ajv({ allErrors: true, removeAdditional: true });

const schema = {
    type: "object",
    properties: {
        username: { type: "string", maxLength: 32 },
        age: { type: "number", minimum: 18 }
    },
    required: ["username"],
    additionalProperties: false // CRITICAL: Drop unknown keys
};

const validate = ajv.compile(schema);

app.post('/v1/register', (req, res) => {
    const valid = validate(req.body);
    if (!valid) {
        return res.status(400).json(validate.errors);
    }
    // Now req.body is sanitized and safe
});

---

THE V8 ENGINE AND THE COST OF HIDDEN CLASSES

You need to understand how V8 works if you want to write secure, high-performance code. When you dynamically add properties to an object (e.g., obj.a = 1; obj.b = 2;), V8 creates “hidden classes” (also called Maps) to track the shape of that object.

If you constantly change the shape of your objects, you force V8 to abandon its optimized JIT (Just-In-Time) compiled code and fall back to a slower, interpreted mode. This isn’t just a performance issue; it’s a security issue. De-optimized code is harder to predict and can lead to side-channel vulnerabilities.

THE VULNERABILITY (BEFORE):

function User(name) {
    this.name = name;
}

const u1 = new User('Alice');
const u2 = new User('Bob');

u1.isAdmin = true; // u1 now has a different hidden class than u2

THE HARDENED DEFENSE (AFTER):
Initialize all properties in the constructor, even if they are null. This keeps the hidden class stable.

// javascript best practice: Maintain stable object shapes
class User {
    constructor(name) {
        this.name = name;
        this.isAdmin = false; // Always define the shape early
        this.permissions = [];
    }
}

const u1 = new User('Alice');
const u2 = new User('Bob');
// u1 and u2 share the same hidden class. V8 is happy.

---

THE MANIFESTO: SURVIVAL THROUGH PARANOIA

I am finishing this report because I have to. Not because I think you’ll listen, but because I need a paper trail for when the auditors from the SEC show up.

JavaScript is a beautiful, flexible language. That flexibility is exactly what the attackers used to gut us. They used the prototype chain to bypass your authentication. They used the event loop to freeze your services. They used your dependencies to gain a foothold in our internal network.

If you want to survive the next 72 hours, you will implement these javascript best practices:

1. Freeze Everything: Use Object.freeze() on every configuration object.
2. No Prototypes: Use Object.create(null) for any object that handles user-supplied keys.
3. Audit Your Life: If a dependency hasn’t been updated in six months, it’s a liability. Kill it.
4. Permission Model: Run Node.js with the --experimental-permission flag. No exceptions.
5. Validate, Don’t Just Parse: JSON.parse is the start of the journey, not the end. Use schemas.
6. Stay Monotonic: Use process.hrtime.bigint() for security-sensitive timing.
7. Respect the Loop: If a function takes more than 10ms, it belongs in a Worker Thread.

I’m going home now. I’m going to delete my Slack, turn off my phone, and sleep for three days. When I come back, if I see a single __proto__ in the codebase, I’m resigning.

You were warned.

SIGNED,
The Auditor
(0xDEADBEEF)

Related Articles

Explore more insights and best practices:

• Pssh Execute Ssh Commands On Multiple Systems Using Single Command
• What Is React A Beginners Guide To The Js Library
• Install Laravel On Ubuntu 16 04 With Apache