Privacy Policy for Script Sentinel
Last Updated:
This Privacy Policy explains how Script Sentinel processes information across our public website, free Content Security Policy scanner, Script Sentinel Premium monitoring product, Chrome and Firefox browser extensions, and the WordPress plugin, including its optional Premium CSP Autopilot. Product-specific disclosures and the premium monitoring and billing flows are covered below.
1. Scope
Script Sentinel provides a free Content Security Policy scanner and generator, a paid premium CSP drift monitoring service, and browser extensions and a WordPress plugin that can initiate scans against the backend.
This policy covers how we process information when you use those products, sign in to a premium account, monitor a site, purchase a plan, receive product emails, or visit pages on our website.
2. Browser Extension Privacy
The Script Sentinel browser extensions are designed to be privacy-first. We do not use them to build advertising profiles, track your browsing history in the background, or sell extension user data.
The extensions do not transmit the active tab URL or start a scan until you explicitly click Generate CSP. They do not collect your browsing history in the background.
2.1 Active Tab URL
When you open an extension, it reads the active tab URL and title to identify the scan target. The title is used only in the extension UI and local scan history; it is not sent to our backend. When you click Generate CSP, the extension sends the active tab URL, selected scan depth, and selected scan options over HTTPS to our backend at https://script-sentinel.com so our scan service can analyze the requested public URL and generate a Content Security Policy candidate.
2.2 Scan Results
Our server-side browser loads the public URL you requested and observes website content and resources such as scripts, styles, fonts, images, frames, links, and network destinations. The generated policy candidate and related scan output are returned to the extension so they can be displayed to you. Extension scans use the public scanner path and are not written to the premium monitoring database.
2.3 Local Extension Storage
Local history is enabled by default. The extensions use browser extension-local storage to save up to your 5 most recent scans, including the scanned URL, page title, scan time, generated policy candidate, and related result details, on your device. You can disable local history or clear it from the extension UI. That local extension history is not synced by us to another device and is not stored in our premium Postgres database.
2.4 Technical Request Data
Extension scans use our public scanner service. When we receive an extension scan request, we may process the requester's IP address, request metadata, and a redacted version of the requested URL for rate limiting, security, abuse prevention, debugging, reliability, and operational monitoring. Query strings and fragments are removed from logged scan targets.
2.5 Chrome Web Store Limited Use
The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements.
3. WordPress Plugin Privacy
The free Script Sentinel WordPress workflow starts a scan only after an authorized WordPress administrator opens Tools → Script Sentinel, accepts the disclosure, and clicks Scan up to 10 pages. It does not scan on activation, on ordinary page loads, through WordPress cron, or in the background.
3.1 Data Sent for a Scan
The administrator's browser sends the site's canonical public HTTPS home URL, selected scan options, and a short-lived one-time site-control proof to Script Sentinel. Our service calls the plugin's fixed public proof route and, after verification, loads up to 10 public pages on the exact canonical origin and within its original base path in a server-side browser. WordPress login cookies, administrator credentials, email addresses, private posts, and other authenticated page content are not requested or sent by the plugin. WordPress scans do not capture a page screenshot and do not create a premium monitoring run or anonymous Script Sentinel scan session.
3.2 Local WordPress Storage
For scan data, the plugin stores only its latest bounded result summary in the site's own WordPress database, including the CSP candidate, score, grade, scanned public page paths, warnings, and scan time. Query strings and fragments are removed from stored page URLs. If an administrator activates CSP deployment, the plugin also stores the active or inactive deployment state, policy and fingerprint, bounded revision and source-scan metadata, canonical site binding, the local WordPress user ID that made the change, one immediately previous deployment snapshot for rollback, and a bounded record of any CSP conflict visible to WordPress. These records are stored in non-autoloaded WordPress options. A pending proof is stored only as a keyed hash for up to five minutes, and a short scan lock prevents duplicate work.
If an administrator connects Premium, WordPress also stores a random installation identity, the approved Autopilot profile, bounded synchronization and command state, managed CSP state, and machine credentials in non-autoloaded options. Pending pairing records and grants are authenticated and encrypted locally with AES-256-GCM using WordPress salt-derived key material or an operator-provided credential key. Encryption limits disclosure from a database-only leak; a fully compromised WordPress or PHP host can still read key material or alter plugin behavior.
3.3 Free Local CSP Actions
A free scan never changes the site's policy automatically. A WordPress administrator may explicitly activate a complete candidate as an enforcing Content Security Policy, deactivate it, or restore the immediately previous deployment. Those actions and ordinary public-page header delivery occur locally in WordPress and do not send a request, cookie, visitor identity, or page content to Script Sentinel. The plugin limits its header to eligible public HTML or XHTML GET and HEAD responses and suppresses it when WordPress can see another enforced CSP. A web server, proxy, CDN, security product, or full-page cache can add or retain headers outside the plugin's view.
Administrators can clear the latest scan result without silently changing an active deployment, deactivate or roll back the local policy, and uninstall the plugin. Uninstall removes plugin-owned options, including multisite options through batched cleanup when applicable: result, proof, lock, deployment, and conflict state. Ordinary plugin deactivation stops its runtime header hook but retains local options unless the plugin is uninstalled.
3.4 Premium Pairing and Five-Minute Agent Synchronization
Premium pairing contact begins only after a WordPress administrator explicitly selects Connect Premium. Pairing sends the canonical public site URL and origin, the public WordPress site name used as an installation label, plugin and platform version information, the selected profile, a short-lived site-control proof, and bounded device-flow and PKCE values. Automatic Autopilot CSP changes begin only after the authenticated Script Sentinel account explicitly approves and enrolls the exact installation and profile. The PKCE verifier and returned machine access and refresh credentials remain in PHP and are not exposed to packaged JavaScript or browser storage.
After connection, the plugin schedules an agent synchronization about every five minutes. Each bounded request can send the installation identity, canonical site binding, plugin and protocol versions, local CSP mode, generation and policy digests, watchdog and lifecycle state, timestamps, command acknowledgements, and bounded error or conflict codes. Script Sentinel can return at most one exact, sequence-bound command for report-only observation, enforcement probation, commit, rollback, or lifecycle maintenance. Ordinary visitor page loads do not contact the agent API. WordPress cron is traffic-driven unless the operator configures a reliable external cron runner, so synchronization may be delayed on a quiet or restricted site.
Autopilot can change CSP state automatically only after that explicit enrollment. Equivalent or tightening candidates may move through bounded report-only testing, isolated enforcing validation, production probation, commit, or rollback. Trust-expanding or otherwise unprovable drift is held for approval of the exact candidate. A local watchdog is designed to restore the prior committed policy after an expired or failed rollout, including when the backend or cron is unavailable.
3.5 Browser CSP Reports
During an active Premium rollout, eligible public responses can include an opaque, write-only Script Sentinel report endpoint. A visitor's browser may then send CSP violation information directly to that endpoint, including disposition, effective directive, blocked resource information, document location, original-policy information, and browser request metadata. As with any internet request, our infrastructure may process network metadata such as the requester IP address and user agent for transport security, rate limiting, abuse prevention, and operational logging.
Report bodies are bounded, parsed in memory, and discarded. Retained report rows contain only reduced disposition and directive values, a normalized blocked-source category, a redacted same-site document path without query strings, fragments, or sensitive segments, a digest of the original policy, ambiguity state, counts, and timestamps. They do not retain raw report bodies, raw original policies, full blocked or document URLs, referrers, samples, cookies, authorization data, or client addresses. Retained aggregates are pruned after at most 30 days. Reports are incomplete and untrusted signals; a missing report is never treated as proof that every site flow works, and report data never adds a source to a policy automatically.
3.6 Service and Site Logs
Script Sentinel may process the requester's IP address, the canonical site URL without query or fragment, request metadata, proof-attempt counters, and site-derived rate-limit records for security, abuse prevention, debugging, reliability, and operational monitoring. The raw one-time proof is not stored as a scan artifact. The WordPress site, its hosting provider, CDN, firewall, or logging tools may record the proof callback request. Proofs expire quickly and are accepted only once to reduce that exposure.
4. Website Scanner and Public Service
When you use the public scanner on our website, we process the URL you submit, run a server-side browser scan, and generate scan artifacts such as the discovered origin, scanned pages, resource URLs, warnings, directives, a recommended CSP, and related score output. For some public scans, the artifact may also include a page snapshot used in the UI.
Because Script Sentinel loads pages in a server-side Chrome browser, the website you ask us to scan and the resources that site loads may receive requests from our scanning infrastructure as part of the scan. If you do not want a site to receive such a request from Script Sentinel, do not submit that URL for scanning.
4.1 Anonymous Session Data
Public scan results are stored in temporary in-memory session state so the scanner UI, downloads, and live CSP editor continue to work during your session. That anonymous session state is separate from premium account storage and is not written to the premium monitoring database.
4.2 Technical Logs
Like most web services, we may process technical request data such as IP address, request metadata, and redacted scan or monitor URLs in application logs for security, abuse prevention, debugging, reliability, and operational monitoring. Query strings and fragments are removed from logged scan and monitor targets.
6. Billing and Transactional Email
6.1 Stripe Billing
Paid subscriptions use Stripe for checkout, subscription management, billing portal access, and webhook-driven subscription updates. We store subscription-related records such as plan, status, current period end, cancel state, Stripe customer identifiers, Stripe subscription identifiers, checkout session references, and Stripe webhook payloads needed to reconcile billing state.
Payment card details are handled by Stripe, not stored directly by Script Sentinel in our application database.
6.2 Transactional Email
We use transactional email for contact email verification codes, site verification confirmations, drift alerts, monitor failure notices, and degraded monitor notices. We store email delivery records such as recipient address, subject, message kind, provider message ID, delivery status, event timestamps, and provider error details when available.
9. Retention
Anonymous public scan session data is temporary and is pruned from in-memory session storage after inactivity. Premium run history is retained according to the active plan's history window, which is currently shorter on Hobby and longer on Developer. Time-limited sign-in and verification artifacts such as OAuth attempts, contact email verification codes, and auth sessions are treated according to their configured expiration windows.
Free WordPress scans are not retained as backend scan artifacts or anonymous session results. The plugin keeps its latest local result until a later result replaces it, an administrator clears it, or the plugin is uninstalled. Local CSP deployment state and one previous rollback snapshot remain until an administrator changes that state or uninstalls the plugin. A bounded conflict record is removed after a later conflict-free eligible response, a deployment action, or uninstall. One-time proof and scan-lock records contain short expiries, become unusable when expired, and may remain inert until a relevant administrator action or uninstall clears them; the plugin does not schedule cleanup work. Operational logs and abuse-control counters may follow separate bounded security and reliability retention practices.
WordPress Autopilot report aggregates are retained for no more than 30 days. Machine access credentials are short-lived, refresh credentials rotate and expire, and revoked-installation audit metadata is retained for no more than 90 days. Active rollout and security records can use their own shorter expiry or cleanup grace periods so an in-flight rollback or credential-reuse investigation is not broken by routine maintenance.
We may retain account, billing, email delivery, webhook, security, and operational records for longer when reasonably necessary to run the service, investigate abuse, resolve disputes, or comply with legal obligations.
10. Your Choices
You can use the public scanner without creating an account, decide whether to upgrade to Premium, remove monitored sites from the dashboard, clear the WordPress plugin's latest local result, deactivate or roll back its locally deployed CSP, decline Premium pairing, revoke or disconnect a linked installation, uninstall the plugin, or contact us with privacy-related questions. If you need help with an account or data request, please reach out through the Contact page.