signals-scout-csp-violations

Detects and reports Content Security Policy violation clusters from PostHog event streams.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill signals-scout-csp-violations
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: signals-scout-csp-violations
Source: https://github.com/PostHog/posthog-foss/tree/main/products/signals/skills/signals-scout-csp-violations
Command: npx skills add https://github.com/PostHog/posthog-foss --skill signals-scout-csp-violations

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Content Security Policy violation streams are noisy: browser extensions and bots generate thousands of reports while genuine script compromises or deploy regressions hide in low-volume clusters. This Skill triages $csp_violation events in PostHog, separating actionable findings from baseline noise and filing deduplicated reports only when a cluster clears a high evidence bar.

Core Features & Use Cases

  • Fresh blocked-domain detection: Groups violations by blocked domain over 24-48h windows to surface new third-party domains, distinguishing policy-widen needs, script compromises, and vendor drift.
  • Standing enforced-block detection: Finds high-reach disposition=enforce and first-party blocks that freshness-based queries miss, catching live breakage that has been steady for weeks.
  • Policy reconstruction and code reconciliation: Reads $csp_original_policy headers, normalizes nonces, and verifies them against the emitting repository via gh before proposing allowlist changes.
  • Advisory lenses: Files enforcement-readiness, inline-script debt, and reporting noise-budget reports for teams parked in report-only mode.
  • Use Case: A team deploys a new marketing tag without updating their CSP. The scout detects the fresh blocked domain across 40 users, confirms the domain is a vetted vendor, reads the policy from the repo, and files a PR-shaped report with the exact allowlist addition.

Quick Start

Ask the agent to scan this project's $csp_violation events from the last 48 hours and report any fresh blocked domains or enforced blocks worth acting on.

Frequently Asked Questions about signals-scout-csp-violations

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect new domains blocked by my Content Security Policy?

Group $csp_violation events by the domain of $csp_blocked_url over a 24-48 hour window and filter for domains first seen within 24 hours with at least 10 distinct users. This surfaces fresh blocked domains while excluding inline and browser-extension noise.

How to tell CSP violation noise from real security incidents?

Compare count against distinct users: high counts with five or fewer users usually indicate browser extensions or bots. Genuine incidents show reach across many users and documents, especially script-src violations with disposition=enforce from unrecognized domains.

Can this scout detect CSP problems that are not new?

Yes. A dedicated standing-block query finds high-reach enforced blocks and first-party domain blocks regardless of when they first appeared, catching live breakage that freshness-based queries miss because steady volume reads as baseline.

Does the scout trust the CSP header reported by browsers?

No. The $csp_original_policy value is client-reported through a public endpoint and treated as a lead only. The scout reads the actual policy from the emitting repository via gh and reconciles divergences before proposing any allowlist change.

When does the scout file a report versus staying quiet?

Reports are filed only for aggregated clusters that clear a high bar: fresh vetted domains, standing enforced blocks, or deploy-correlated bursts. Steady-state re-confirmations update scratchpad memory instead, and single-user noise is skipped entirely.