Security at StorefrontShield
Security is the product, so our own controls should be understandable too. This page explains our current approach without exposing sensitive operational details.
Last reviewed June 23, 2026
Our security principles
- Collect less: we limit scan inputs and avoid collecting storefront credentials or payment information.
- Passive by design: free scans observe public browser-side resources without exploiting, authenticating, or submitting forms.
- Keep evidence private: scan inventories and baselines are stored in non-public object storage.
- Fail safely: missing anti-abuse or security configuration blocks new scan requests instead of silently weakening controls.
- Human judgment remains: automated findings are evidence for review, not automatic declarations that a vendor or script is malicious.
Infrastructure and application controls
- Cloudflare provides edge hosting, encrypted transport, DDoS protection, browser isolation, queues, and private storage.
- Cloudflare Turnstile and application rate limits reduce automated abuse and uncontrolled browser usage.
- Submitted URLs are restricted to public HTTPS storefronts; local addresses, private-network addresses, embedded credentials, and custom ports are rejected.
- Scan jobs run asynchronously and are isolated from the public website request path.
- Secrets such as email API credentials are held in encrypted platform secret storage and are not committed to source control.
- Security headers restrict framing, content types, browser capabilities, and permitted resource origins.
- Operational events are logged to support failure investigation and usage monitoring.
- Google Cloud Web Risk may be used to enrich reports with point-in-time URL reputation signals. These signals are displayed separately from our script analysis and do not replace human review.
Data protection
Scan reports can reveal a merchant's technology and vendor footprint, so report files and raw inventories are not published. Rate-limit identifiers are stored as keyed cryptographic hashes rather than raw IP addresses, email addresses, or storefront domains in the application database. See our Privacy Policy for collection and retention details.
Scan boundaries
A free scan starts with the public URL submitted by an authorized user and may follow representative public product, collection, category, or cart links on the same storefront. It does not enter checkout or test passwords, payment forms, administrative interfaces, APIs, or vulnerabilities. External reputation sources can produce false positives or false negatives. The scan does not prove that a site is secure, and it may not observe scripts that require another location, consent choice, account state, or user interaction.
Responsible disclosure
If you believe you found a security vulnerability in StorefrontShield, email [email protected]. If that address is unavailable, use [email protected].
Please include a clear description, affected URL or component, reproduction steps, and potential impact. Do not access customer data, disrupt the service, use social engineering, perform denial-of-service testing, or publicly disclose an unresolved issue.
What to expect
We will acknowledge a credible report as soon as practical, investigate it, and communicate material progress when possible. We ask researchers to give us reasonable time to remediate before disclosure.
Current assurance status
StorefrontShield is an early-stage service. We do not currently claim SOC 2, ISO 27001, PCI assessor, penetration-test, or bug-bounty certification. We will update this page as independent assurance and formal policies are added.