NodeJS Security Flashcards

24 sample cards from the Security deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

1. What is Validator.js, and how does it differ from Joi?

   Validator.js is a library of string validation and sanitization functions (e.g. isEmail, isURL, isUUID, normalizeEmail). It validates individual string values, whereas Joi validates entire structured objects against a declarative schema.

2. Name five common Validator.js validation functions and what they check.

   isEmail (valid email format), isURL (valid URL), isUUID (valid UUID), isLength (string length within bounds), and isNumeric / isInt (numeric or integer strings). Validator.js operates on string inputs.

3. What is the difference between validation and sanitization, and which does Validator.js support?

   Validation checks whether input meets rules and returns a boolean; sanitization transforms/cleans input into a safe canonical form. Validator.js supports both, with validators (isX) and sanitizers (e.g. trim, escape, normalizeEmail, toBoolean).

4. What is Helmet in Express, and what does it do?

   Helmet is Express middleware that sets a collection of HTTP security response headers with safe defaults to help protect the app from common web vulnerabilities (XSS, clickjacking, MIME sniffing, etc.). You add it with app.use(helmet()).

5. Which HTTP header does Helmet set to mitigate clickjacking, and what does it do?

   X-Frame-Options (set to SAMEORIGIN or DENY). It controls whether the page may be rendered inside a frame/iframe, preventing clickjacking by disallowing the site from being embedded by other origins.

6. What is Content-Security-Policy (CSP), and how does Helmet relate to it?

   CSP is a header that whitelists the sources from which resources (scripts, styles, images) may load, mitigating XSS and injection. Helmet can set the Content-Security-Policy header (via helmet.contentSecurityPolicy()), though it must usually be configured explicitly for your app.

7. What does the Strict-Transport-Security (HSTS) header do, and does Helmet set it?

   HSTS tells browsers to only communicate with the site over HTTPS for a specified max-age, preventing protocol-downgrade and SSL-stripping attacks. Helmet enables it by default via helmet.hsts().

8. What is the purpose of the X-Content-Type-Options: nosniff header set by Helmet?

   It instructs the browser not to MIME-sniff (guess) a response's content type and to trust the declared Content-Type, preventing attacks where a file is interpreted as a different, executable type (e.g. treating an upload as a script).

9. What is rate limiting, and why is it used?

   Rate limiting caps how many requests a client (usually identified by IP or API key) can make in a given time window. It protects against brute-force attacks, credential stuffing, denial-of-service, and API abuse, and helps ensure fair resource usage.

10. In a fixed-window rate limiter, how do you express the allowed request rate?

    As a maximum count of requests per window: $$\text{rate} = \frac{\text{max requests}}{\text{window duration}}$$ e.g. $\frac{100\ \text{requests}}{15\ \text{minutes}}$. Once the counter reaches max within the window, further requests are rejected until the window resets.

11. Compare the fixed-window and sliding-window rate-limiting algorithms.

    Fixed window counts requests in discrete time buckets and resets at each boundary, but allows bursts of up to 2x the limit around the boundary. Sliding window smooths this by weighting the previous window's count, giving a more accurate rolling rate at higher computational cost.

12. Explain the token bucket rate-limiting algorithm.

    A bucket holds up to a capacity of tokens and refills at a fixed rate r tokens per second. Each request consumes one token; if the bucket is empty the request is throttled. It permits short bursts (up to bucket capacity) while enforcing an average rate over time.

13. Which HTTP status code and headers typically signal a rate-limit rejection?

    HTTP 429 Too Many Requests. Servers often add a Retry-After header (seconds until retry) and informational headers like RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset.

14. Why should a distributed/multi-instance API store rate-limit counters in a shared store like Redis?

    Because in-memory counters are per-process, so with multiple server instances each would track its own count, letting a client exceed the intended global limit. A shared store (e.g. Redis) gives a single authoritative counter across all instances.

15. What is CORS, and what problem does it address?

    CORS (Cross-Origin Resource Sharing) is a browser security mechanism using HTTP headers that lets a server relax the Same-Origin Policy and explicitly permit web pages from other origins to access its resources. It controls cross-origin browser requests, not server-to-server calls.

16. How is an 'origin' defined for the Same-Origin Policy and CORS?

    An origin is the tuple of scheme (protocol) + host + port. Two URLs share an origin only if all three match; any difference (e.g. http vs https, different subdomain, or different port) makes them cross-origin.

17. Which response header is central to CORS, and what does it specify?

    Access-Control-Allow-Origin. It tells the browser which origin(s) are permitted to read the response, either a specific origin (e.g. https://app.example.com) or the wildcard * (which cannot be used with credentials).

18. What is a CORS preflight request, and when is it triggered?

    A preflight is an automatic OPTIONS request the browser sends before the actual 'non-simple' request to ask permission. It is triggered by non-simple methods (PUT, DELETE, PATCH), custom headers, or certain Content-Types, and the server must answer with the appropriate Access-Control-Allow-* headers.

19. What defines a CORS 'simple request' that does not require a preflight?

    A simple request uses GET, HEAD, or POST; includes only CORS-safelisted headers; and, for POST, uses a Content-Type of application/x-www-form-urlencoded, multipart/form-data, or text/plain. Such requests skip the preflight OPTIONS step.

20. How do you allow credentials (cookies/authorization headers) in CORS, and what constraint applies?

    Set Access-Control-Allow-Credentials: true and have the client send credentials. The constraint: Access-Control-Allow-Origin must then be an explicit origin, not the wildcard *, or the browser will block the response.

21. Which CORS response headers govern allowed methods and headers on preflight, plus preflight caching?

    Access-Control-Allow-Methods lists permitted HTTP methods, Access-Control-Allow-Headers lists permitted request headers, and Access-Control-Max-Age sets how long (seconds) the browser may cache the preflight result to avoid repeating it.

22. Is CORS a defense against server-side attacks like CSRF or a substitute for authentication? Explain.

    No. CORS is enforced by the browser and only governs whether cross-origin JavaScript can read a response; it is not authentication or authorization and does not by itself stop CSRF. Non-browser clients ignore CORS entirely, so servers still need proper auth and CSRF protections.

23. Compare Joi and Validator.js in terms of scope and typical use case.

    Joi validates whole structured objects against a declarative schema (great for validating request bodies/config). Validator.js provides individual string validators and sanitizers (great for checking or cleaning a single field like an email). They are often complementary.

24. Contrast session-based authentication with stateless JWT authentication.

    Session-based auth stores session state server-side and gives the client a session ID cookie, requiring a server lookup per request but allowing easy revocation. JWT auth is stateless: the token itself carries signed claims, so no server store is needed, but tokens are harder to revoke before expiry.

What this deck covers

Security flashcards FAQ