Trust Center
Security Architecture
How Script Sentinel limits scanner access, protects browser requests, and handles the evidence needed to generate and monitor Content Security Policies.
Bounded public scanning
Scheduled and free scans use an isolated, bounded Chrome process for public HTTP and HTTPS pages. A canonical public-egress policy is applied to initial DNS resolution, redirects, resolved answers, connected peers, and the Chrome proxy so private, loopback, link-local, special-use, and provider-metadata destinations are rejected.
Scheduled scans do not store site credentials and do not log in to authenticated areas. Browser-extension captures are user-triggered and remain a separate workflow.
Evidence, privacy, and limits
Scanner output is bounded evidence from pages and states the run actually reached. It can miss authenticated, conditional, consent-gated, lazy-loaded, feature-flagged, and user-triggered behavior.
Premium artifacts redact query strings, fragments, credentials, and token-like identifiers before persistence. Retained monitor history follows the account's plan window, and expired operational records are cleaned independently of new scans.
Account and request protection
Google and GitHub sign-in flows use state, nonce, and PKCE checks. Authenticated actions use CSRF tokens, browser POST origin checks, bounded request bodies, server-side sessions, and secure cookie settings on HTTPS origins.
Script Sentinel generates reviewable recommendations. It never automatically deploys or enforces a policy, and quiet scan or report evidence is not proof of safety, certification, or compliance.
Service subprocessors
These services process only the data needed for their stated role:
- Render
- Application hosting and managed PostgreSQL persistence.
- Stripe
- Checkout, subscriptions, billing portal access, and payment records.
- Resend
- Transactional, monitoring, verification, and support email delivery.
- Google or GitHub
- OAuth identity data only when that provider is selected for sign-in.