Explore

Set security headers on all HTTP responses: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security. Missing headers leave your app vulnerable to XSS, clickjacking, MIME sniffing, and protocol downgrade attacks.

Never use eval(), new Function(), or vm.runInScript() with user-provided input. These functions execute arbitrary code with the full privileges of your Node.js process — an attacker can read files, access databases, or take over the entire server.

Sanitize and escape all user-provided input before rendering in HTML, executing in SQL, or passing to system commands. Unsanitized input is the entry point for XSS, SQL injection, and command injection attacks — the three most exploited vulnerability classes in web applications.

Store all environment-specific configuration (API URLs, database connections, feature flags) in environment variables, never in source code. Hardcoded config means your staging code talks to production databases, your API keys are in git history, and deploying to a new environment requires code changes.

Pin exact versions for all dependencies in production (no ^, ~, or * ranges). Unpinned dependencies silently pull in new versions that can introduce breaking changes, security vulnerabilities, or performance regressions — and you won't know until production breaks.

Never commit API keys, passwords, tokens, or credentials to version control. Once a secret is in git history, it is permanently exposed — even deleting the file doesn't remove it from history, and anyone who cloned the repo has a copy forever.

Each commit should contain exactly one logical change. Commits that mix refactoring, bug fixes, and features together make git bisect useless, code review painful, and reverting a single change impossible without losing everything else in the commit.

Write commit messages that explain WHY a change was made, not just WHAT changed. "fix bug" tells future-you nothing — "fix: prevent duplicate form submission on slow connections" tells you the context, the cause, and the scope without reading any code.

Minimize use of arbitrary values like [w-347px], [color:#1a2b3c]. Arbitrary values bypass Tailwind's design tokens, making the design system meaningless and creating one-off values that are impossible to maintain consistently.

Use Tailwind's responsive prefixes (sm:, md:, lg:) and theme tokens instead of arbitrary pixel values. Arbitrary values ([w-347px]) bypass the design system, creating inconsistent spacing/sizing that doesn't adapt to different screen sizes.

Text must meet WCAG AA contrast ratio: 4.5:1 for normal text, 3:1 for large text. Low-contrast text is unreadable for users with low vision, color blindness, or anyone using a screen in bright sunlight — affecting up to 8% of male users (color blindness alone).

Every interactive element must be operable via keyboard alone (Tab, Enter, Space, Escape). Users with motor disabilities, RSI, or broken trackpads cannot use a mouse — if your app requires mouse interaction, those users are completely locked out.

Every <img> must have a meaningful alt attribute. Without alt text, screen readers either skip the image entirely or read the raw filename ("DSC_0042.jpg"), leaving visually impaired users completely unable to understand the content.

Use semantic HTML elements (<nav>, <main>, <article>, <button>) instead of generic <div> and <span> with click handlers. Screen readers and assistive technology rely on semantic elements to understand page structure — a <div onClick> looks like nothing to a blind user.

Test what the code does (outputs, side effects), not how it does it (internal method calls, private state). Implementation-coupled tests break every time you refactor, even when behavior is unchanged — making tests a liability instead of a safety net.

Every test must be independent — no shared mutable state, no execution order dependencies. When tests share state, they pass in isolation but fail together (or worse, fail randomly), creating flaky CI that wastes hours of debugging time.

Use factory functions (e.g., `createUser({role: 'admin'})`) instead of static JSON fixtures. Factories let you create exactly the data each test needs with sensible defaults, while fixtures force you to maintain large JSON files where a change to one test's data breaks another test.

Use `unknown` instead of `any` for values with uncertain types. Unlike `any`, `unknown` forces you to narrow the type before using it, keeping type safety intact.

Model mutually exclusive states with discriminated unions, not optional fields. Optional fields allow impossible states (e.g., `status: 'success'` with `error: 'failed'`) that compile but crash at runtime.

Enable all strict flags in tsconfig.json (strict: true). Without strict mode, TypeScript allows null access, implicit any, and unchecked function calls that will crash at runtime.

Avoid `as Type` assertions — they tell TypeScript "trust me" and skip validation. If the runtime value doesn't match, your code crashes with no type error to warn you.

Validate and sanitize all request input (body, query params, headers) before processing. Unvalidated input is the root cause of injection attacks, data corruption, and crashes from malformed data.

Return semantically correct HTTP status codes (400 for bad input, 401 for unauthenticated, 403 for unauthorized, 404 for missing, 500 for server errors). Using 200 for everything hides errors from monitoring, breaks caching, and makes debugging impossible.

Apply rate limiting to all public-facing API endpoints. Without rate limits, a single attacker can overwhelm your server, exhaust your database connections, or brute-force authentication — taking down the service for all users.