CSP Interview Questions: Nonces, Strict Policies, and Report-Only Rollouts

A Content Security Policy can look strict while allowing the execution path an attacker needs. Host allowlists inherit trust in every allowed host, a reused nonce becomes a standing capability, and a Report-Only header can produce reassuring dashboards without blocking anything.

This guide prepares you to answer content security policy interview questions with a diagnostic method, a concrete state trace, and evidence you can defend. It is not a leaked question bank or a claim that every employer uses the same interview format.

Article thesis: Start from executable trust, not a list of domains. Generate a fresh unpredictable nonce per response, attach it only to intended bootstrap scripts, use a strict policy that propagates trust deliberately, deploy through Report-Only with representative traffic, and promote to enforcement only after violations are classified and rollback is ready.

Evidence boundary: Official documentation supports the platform and security mechanics cited below. We did not find a reliable, current corpus of candidate reports that establishes a universal interview sequence for this topic.

To rehearse the same boundary-first reasoning with candidate-reported material, start with Design input validation and error handling; use it as practice evidence, not as a prediction of a specific interview.

CSP Interview Questions: Quick Answer

Start from executable trust, not a list of domains. Generate a fresh unpredictable nonce per response, attach it only to intended bootstrap scripts, use a strict policy that propagates trust deliberately, deploy through Report-Only with representative traffic, and promote to enforcement only after violations are classified and rollback is ready.

A strong answer begins by drawing the source of truth and the boundary that can fail. It then distinguishes prevention, detection, and recovery; walks one ordinary case and one adversarial case; and names the evidence that would change the diagnosis. Tool names belong after the invariant, not before it.

Start with the five urgent questions

• What does a nonce authorize, and why must it change per response?
• How does strict-dynamic change trust propagation?
• Which browsers or fallback behavior must the policy support?
• How do you separate real breakage from extensions and noise in reports?
• What evidence is required before enforcement?

These questions prevent a polished answer from solving the wrong problem. If the interviewer leaves a value unspecified, state a conservative assumption and show where it enters the design. When the constraint changes, update the affected boundary rather than replacing the whole answer.

Separate documented facts, reports, and inference

Official documentation — MDN Content Security Policy guide: MDN documents nonce- and hash-based policies, strict policies, and Report-Only deployment for collecting violations before enforcement.

Official documentation — W3C Content Security Policy Level 3: The CSP3 specification defines source-list matching, nonces, hashes, strict-dynamic, and violation reporting behavior.

Official documentation — web.dev strict CSP: Google web.dev recommends nonce- or hash-based strict CSP patterns and testing before enforcement.

Candidate reports: No reliable same-cycle set of public reports establishes a standard prompt order, scoring rule, or expected vendor configuration for this general topic. Individual reports can suggest practice areas, but they cannot establish prevalence.

Engineering inference: The diagnostic sequence in this article is designed to make the documented mechanics testable in an interview. It is a preparation framework, not an official rubric.

Draw the diagnostic boundary map

Boundary	Question or state	Defensible response	Failure to expose
Nonce creation	fresh cryptographically strong value per response	template receives the value; intended script tag gets it	nonce reuse or user-controlled placement
Bootstrap trust	small reviewed script set	script-src nonce or hash plus deliberate trust propagation	broad host allowlist
Observation	Report-Only on representative pages	sampled reports joined with release and route	extension noise mistaken for breakage
Enforcement	staged cohort with rollback	blocking header and canary metrics	instant global policy change

This boundary map is the first article-specific asset. Read it left to right. For every transition, name the initiator, the identity carried with the action, the policy decision, the durable result, and the observation that proves success. When a result is unknown, prefer inspection or reconciliation before repeating a side effect.

Work through a concrete interview scenario

A server renders a checkout page with one bootstrap bundle and a payment provider loaded by that bundle. The response creates nonce N1, puts N1 in the header and only on the bootstrap tag, and does not reuse it for the next response. Report-Only traffic shows an inline analytics snippet and an extension-injected script. The team removes or hashes the owned snippet, filters extension noise for analysis, canaries enforcement, and watches checkout completion plus violation rate.

Narrate the trace in chronological order. Separate facts you have observed from hypotheses you still need to test. A status code, log line, or green dashboard is only one observation; it may not prove the durable business outcome. State what would falsify your current explanation.

The supporting visual is the second article-specific asset. Use it to explain the normal path, the first boundary that can fail, the evidence collected there, and the recovery path. The interviewer should be able to change one condition and see exactly which edge of the diagram changes.

Show a small implementation or review skeleton

response_nonce = secure_random_base64()
header = "Content-Security-Policy-Report-Only: " +
         "script-src 'nonce-" + response_nonce + "' 'strict-dynamic'; " +
         "object-src 'none'; base-uri 'none'; report-to csp"
render_template(nonce=response_nonce)
# promote the reviewed policy to Content-Security-Policy in stages

The skeleton is deliberately compact. In an interview, explain the behavior around it: parsing, identity, timeouts, concurrency, cancellation, cleanup, authorization, observability, and version-sensitive assumptions. Production code also needs framework-specific error handling and tests; the point here is to expose the control decisions.

A useful code-review question is, “What fact makes the next transition safe?” If the answer is only that the previous call returned, add a durable check. If an action can repeat, define whether repetition resumes the same operation, creates a new attempt, or creates a new business effect.

Diagnose four misleading answers

Tempting answer	Why it fails	Better response
Reuse one nonce until deployment	Any exposed nonce remains useful	Create a new unpredictable nonce for every response
Allow a CDN wildcard	All script paths on that origin inherit trust	Authorize reviewed bootstrap code with nonce/hash
Treat Report-Only as protection	Nothing is blocked	Label observation and enforcement separately
Enforce after one clean local run	Production routes and third parties differ	Canary representative traffic with rollback metrics

For each misleading answer, reproduce the smallest counterexample, name the violated invariant, apply one narrow repair, and rerun the same case. Changing several layers at once may make the symptom disappear without proving which change fixed it.

Design the test matrix before naming tools

Use at least four classes of tests:

1. Normal path: the smallest valid input reaches the intended durable result.
2. Boundary path: an empty, maximum, ambiguous, stale, or repeated input exercises the contract edge.
3. Failure path: inject one timeout, dependency failure, process interruption, policy denial, or capacity limit.
4. Recovery path: prove the system reaches a known state without guessing whether an earlier effect occurred.

Keep fixtures deterministic. Record versions, configuration, time, identity, and the injected fault. Assert both the immediate response and the later durable state. A test that observes only the UI or only the log can miss a duplicated, lost, or unauthorized effect.

Measure what the answer promises

• violations by directive, route, release, and disposition
• sampled blocked URI origin without sensitive query data
• owned-script fixes versus extension/noise classifications
• page error and business-conversion guardrails
• enforced-policy coverage by response class

Avoid unsupported percentage improvements. State the workload, baseline, window, sample size, and measurement point. Separate averages from tail behavior and application failures from experiment or infrastructure failures. A dashboard should make a bad hypothesis easier to reject, not merely make the system look active.

Use this answer structure in the interview

1. Restate the requirement and define the source of truth.
2. Name one invariant that must survive every transition.
3. Draw the trust, process, network, or data boundaries.
4. Walk a concrete example with identities and state changes.
5. Inject one failure and distinguish known from unknown outcomes.
6. Recover through verification, reconciliation, rollback, or bounded retry.
7. Name measurements, tests, and the trade-off your design chooses.

This structure keeps the answer adaptable. When the interviewer adds scale, security, concurrency, or availability constraints, place the new fact on the diagram and revise the relevant mechanism. Memorizing a product checklist is less useful than showing which assumption each control protects.

Common follow-up questions

What makes an answer senior-level?

Senior answers make ownership and uncertainty explicit. They identify the authoritative state, protect tenant or user boundaries, define what happens after an unknown result, and propose evidence that could disprove the design. Extra components do not substitute for these decisions.

Should I memorize every vendor setting?

Memorize the state model and a few diagnostic examples. Treat version-sensitive settings as facts to verify against current documentation. In the interview, explain how you would inspect the live configuration rather than inventing a default.

How should I use candidate reports?

Use a report as one person’s account of a prompt or process. Record the date, role, location, and source when available. Do not turn one report into a universal employer rule or a frequency claim. For these general technical topics, official mechanics and reproducible reasoning carry more weight.

What should I do when the outcome of an action is unknown?

Do not repeat a side effect blindly. Inspect durable state using a stable operation identity, reconcile the intended result, and retry only when the operation is idempotent or the business rule defines safe repetition.

How much detail should I include?

Go deep on the boundary that determines correctness. Give one normal trace, one failure trace, one recovery trace, and the measurements that validate them. Mention alternative tools only when they change a stated trade-off.

Final preparation checklist

• Define identity, lifetime, ownership, and source of truth.
• Separate documented fact, candidate report, and engineering inference.
• State the invariant before the product or tool name.
• Trace normal, boundary, failure, and recovery behavior.
• Treat unknown results differently from confirmed failures.
• Protect authorization and tenant scope at every boundary.
• Record version-sensitive assumptions and current sources.
• Measure the promised outcome and its failure surface.
• Keep fixtures deterministic and verify durable state.
• Finish with one explicit trade-off and one falsifiable test.

Sources and Further Reading

• MDN Content Security Policy guide
• W3C Content Security Policy Level 3
• web.dev strict CSP

Research note: Sources were checked on 2026-09-13. Official documents support the cited mechanics. Candidate-report evidence does not establish a universal interview format for this topic.