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.

5. Premium Accounts and Monitoring

Script Sentinel Premium adds authenticated dashboards, recurring monitoring, run history, alerts, billing status, and site ownership verification. To operate those features, we store additional account and monitoring data.

5.1 Account and Sign-In Data

When you sign in to Premium, we process your Google or GitHub provider identity, trusted provider email, optional verified contact email, OAuth sign-in attempt records, auth session records, login timestamps, and the signed session cookie needed to keep you authenticated in the dashboard.

5.2 Site and Verification Data

When you add a monitored site, we store the site name, start URL, origin, selected scan options, verification token details, verification path, and verification timestamps so we can confirm ownership and operate recurring scans.

5.3 Monitor Runs and Drift History

Premium monitoring stores run history and review data, including generated CSP lines, directives, warnings, status, timestamps, raw scan artifact data, drift diffs, baseline acceptance state, and manual scan activation records. This is what powers the dashboard, drift comparison views, exports, and alerting.

5.4 Linked WordPress Installations

For an approved Premium WordPress connection, we store the owning account and verified site relationship, the installation identity and display label, immutable grant scopes and Autopilot profile, token-family hashes, agent contact and conflict state, bounded commands and acknowledgements, rollout candidates and state-machine evidence, privacy-reduced CSP report aggregates, and audit timestamps. Raw machine credentials, pairing proofs, PKCE verifiers, report tokens, and raw browser report bodies are not retained in readable service records.

5.5 Site or Installation Removal

If you remove a monitored site from the dashboard, the associated monitoring records for that site are deleted from the premium monitoring store as part of that removal flow. Revoking or disconnecting a WordPress installation ends new machine access and report ingestion and initiates the bounded cleanup rules for machine and rollout records. Some revoked-installation audit metadata may remain for up to 90 days for security and lifecycle integrity.

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.

7. Cookies and Local Storage

Script Sentinel uses essential cookies to operate the service. On HTTPS, the public website uses __Host-ss_session for anonymous session state and Premium uses __Host-ss_auth for authentication. Localhost development uses the legacy ss_session and ss_auth names.

These cookies support core product behavior rather than advertising. We do not currently use first-party analytics cookies or ad-tech cookies on the site.

The browser extensions separately store recent scans in extension-local storage on your device as described above. Free WordPress scan requests omit browser credentials and do not use Script Sentinel session or authentication cookies; the plugin's latest result and local CSP deployment/conflict state remain in the WordPress database controlled by the site operator.

8. Third-Party Services and Sharing

We do not sell your personal information or sell scan history. We share information only as needed to operate the service, process subscriptions, deliver product email, host the application, or comply with legal obligations.

Relevant service providers and recipients include:

  • our hosting and database providers that run Script Sentinel Premium infrastructure;
  • Stripe, for subscription checkout, billing portal actions, and billing webhooks;
  • Resend, for transactional email delivery and delivery event reporting;
  • the websites and resources your requested scan loads, because our scanner must request them to analyze CSP behavior.

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.

If we materially change this Privacy Policy, we will update the date shown above and publish the revised policy on this page.