Scenario
You own a multi-site web platform. Security wants centralized CSP, Permissions-Policy, deprecation, and intervention reports so incidents do not depend on user screenshots. Engineering proposes the Reporting API: declare endpoints with Reporting-Endpoints, receive application/reports+json, and optionally observe reports in-page with ReportingObserver. Explain the adoption decision, staged launch, and success metrics.
What the interviewer evaluates
- Turning earlier browser-problem detection into measurable user and business outcomes.
- Understanding that the Reporting API is best-effort, not a reliable message channel.
- Handling browser support, endpoint security, privacy, and data governance.
- Designing progressive rollout, deduplication, and rollback gates.
Clarifying questions
Confirm report types, target browsers, number of sites, current CSP/deprecation baseline, retention requirements, and alert-handling capacity. Ask whether the endpoint already has authentication, whether URL fragments may be sent, and whether the goal is fewer incidents, lower time to repair, or compliance evidence.
30-second answer
I would adopt it as a low-cost, non-critical diagnostic signal. Start with report-only mode and a small site sample; accept only approved report types and add rate limits, deduplication, and redaction while retaining existing logs. Measure actionable-report rate, time from first report to fix, false-positive rate, endpoint cost, and old-browser coverage. Expand only after data-quality and privacy review. No security decision should depend on guaranteed delivery.
Step-by-step reasoning
1. Frame the problem and alternatives
The Reporting API can carry CSP, Permissions-Policy, COEP, Integrity, deprecation, crash, and intervention reports. Compare it with existing RUM SDKs, server logs, and browser consoles on incremental coverage, client cost, data sensitivity, and operations.
2. Define a minimum viable signal
Start with csp-violation and deprecation, using a logical queue per type. Validate Content-Type: application/reports+json server-side; cap payload size, source, and fields; deduplicate by site, version, and fingerprint. An endpoint outage should lose diagnostics only, never page requests.
3. Handle reliability and compatibility
The specification says delivery is not guaranteed; user agents may drop reports because of network or policy conditions. MDN notes that support is strongest on newer browsers and may be absent on older devices. Segment coverage by browser version and keep server logs plus ReportingObserver as complements. Zero received reports never proves zero violations.
4. Set privacy, security, and launch gates
Reports can include URLs, user agents, and policy details. Use HTTPS, authentication or unguessable paths, query-parameter filtering, bounded retention, and access audits. Begin report-only on internal sites and 1% of traffic; watch endpoint load, sensitive fields, and actionable rate. Disable endpoint configuration if PII leaks, cost spikes, or an alert storm appears.
High-quality sample answer
I would position this as an early-diagnostics layer for browser policy and deprecations, not a new logging system. The decision has three gates. First, value: sample 10 representative sites in report-only mode, verify that reports locate existing tickets, and baseline mean time to detection. Second, risk: security and privacy review endpoint fields, retention, cross-site isolation, and access control. Third, operations: load-test report bursts and set per-source quotas, deduplication keys, and drop-rate monitoring. Because delivery is best-effort, retain RUM, server logs, and a manual fallback. After launch, show coverage by browser family and track actionable rate, MTTR, false positives, reports per million pages, and cost by report type. If a browser has weak coverage, limit conclusions to covered traffic. If the endpoint misbehaves, remove the Reporting-Endpoints response header to roll back without changing core page requests.
Common mistakes
- Treating the Reporting API as a reliable queue or compliance audit record.
- Declaring success from fewer reports without correcting for browser coverage.
- Storing raw URLs, query parameters, and user agents indefinitely.
- Discussing SDK integration without endpoint rate limits, deduplication, cost, or ownership.
- Enabling every site at once without report-only, sampling, or rollback criteria.
Follow-up questions and responses
“Why not use ReportingObserver?”
It is easier for in-page experiments and custom handling, but a crashed page cannot keep observing. A remote endpoint can receive reports independently of page lifetime. They can complement each other, but neither guarantees delivery.
“How would you prove the product works?”
Use a before/after comparison of detection time, repair time, actionable rate, and false positives for confirmed issues, segmented by browser coverage. Monitor endpoint cost and privacy events at the same time.
“What about unsupported browsers?”
Treat the support matrix as a product constraint, retain server logs and RUM, and scope conclusions to covered traffic. Do not inject an expensive polyfill merely to make coverage look uniform.