Security at Shield

At a glance

This page describes Shield’s security posture in concrete detail. Each section answers a question you or your security team are likely to ask. If something is unclear, missing, or feels light, mail our contact form and we’ll respond within one business day.

How we handle your data

Our data minimization is deliberate. Every byte we hold is a byte that could be lost, leaked, or subpoenaed. We hold as little as possible to make Shield work.

Data we store

Data we never store

• Source code submitted for obfuscation. Processed in-memory in the obfuscation engine and discarded when the HTTP response completes.
• Obfuscated output. Same path: returned to you in the response, not retained.
• Card numbers, CVCs, expiry dates. Collected by Stripe Elements in a domain-isolated iframe; we receive only a tokenized PaymentMethod ID.
• Plaintext API keys. Hashed at creation; the plaintext appears once on the screen and is then gone forever.
• Passwords. Sign-in is passwordless — we don’t use or store account passwords at all.
• Raw IP addresses. Hashed to a 16-character SHA-256 prefix at the moment of capture. The raw IP is not stored or logged.

We do not store your code

This is the question we’re asked most. The answer: source code submitted to Shield is processed in-memory and never written to disk or any database.

Concretely, the lifecycle of a single obfuscation request is:

1. HTTPS request arrives at our managed edge (on AWS) and is routed to the Node.js service
2. The service parses the JSON body into a JavaScript string in memory
3. The obfuscation engine runs in a worker thread (off the main event loop, so one job can’t stall the service). AST parsing, transforms, defense injection — all in memory.
4. The protected output string is JSON-encoded into the HTTP response
5. The response is flushed to the network
6. The strings are garbage-collected when the request handler returns

Only the metadata of the request — timestamp, kind, level, byte counts, duration, anonymized IP hash, your user ID — is persisted to the audit log table. The source and output bytes are not.

This is verifiable against our source code. The relevant endpoint handlers (e.g. app/api/obfuscate/route.ts) hold the source in a parameter, pass it through the engine (in a worker thread), return the result, and do not write it. We are happy to walk through this with your security team on request.

Account & authentication

Passwordless sign-in

Shield uses passwordless, magic-link authentication for every account — administrators included. To sign up or sign in you enter your email and receive a unique one-time link; clicking it confirms the address and starts your session. There is no password anywhere to leak, phish, guess, or reuse. Link tokens are 32 bytes of randomness, stored only as a SHA-256 hash, single-use, and expire in 20 minutes.

Sessions

Login creates a DB-backed session record with a cryptographically random 64-character session ID. AHttpOnly, SameSite=Lax, Secure cookie carries the ID; everything else (user_id, expires_at, user_agent, anonymized ip_hash, last_seen_at) lives in the database. Hard expiry: 30 days. Idle expiry: 10 minutes (rolling — any authenticated request slides the window).

Single-session anti-account-sharing: every successful login deletes all other sessions for that user. Two devices cannot be logged in simultaneously. Designed to deter password sharing across organizations.

API keys

Each key is a 32-byte random token, base-prefixed withshield_. We store the SHA-256 hash of the secret portion only. The plaintext key is rendered to your browser exactly once — at creation — and then irretrievable. Lost keys cannot be recovered; they must be re-generated. Revoke any time from Dashboard → API keys.

Signup abuse prevention

Because sign-in is passwordless, every account is provably tied to a reachable inbox. On top of that we reject disposable / temporary-mail domains at signup, and collapse the Gmail dot/“+tag” aliases that resolve to one mailbox so a single inbox can’t farm multiple free accounts. An input passing these checks still has to click a live email link before it can use the tool.

Encryption

In transit

Every endpoint serves over HTTPS. TLS is terminated and certificates are provisioned and rotated automatically by our managed edge; plain HTTP is redirected to HTTPS. The app publishes Strict-Transport-Security with a two-yearmax-age, includeSubDomains, and preload, alongside a set of hardening headers on every response: X-Frame-Options: DENY (anti- clickjacking), X-Content-Type-Options: nosniff, a strict Referrer-Policy, and a locked-down Permissions-Policy.

At rest

Storage encryption is provided transparently by our managed AWS platform: the PostgreSQL database and all managed volumes are encrypted at rest. Application secrets (Stripe keys, email keys, the token-encryption key) live in the platform’s encrypted environment variables, never in the code repository. Avatar images are stored in PostgreSQL, so the application keeps no local filesystem state.

Application-level protection is applied to sensitive values on top of storage encryption:

• API keys: SHA-256 hash (one-way)
• Magic sign-in link tokens: SHA-256 hash, single-use, 20-minute TTL
• GitHub PATs: AES-256-GCM (fails closed if the encryption key is unset — never stored in plaintext)
• Session IDs: not encrypted (entropy is the protection — 256 bits)

In memory

Sensitive values are not logged. The obfuscation engine receives source code strings and discards them when the request completes; we do not write them to stdout, stderr, or the database. Process memory is not deliberately zeroed (Node’s GC handles reclamation), which is a known trade-off documented here for completeness.

Application security

• Input validation: every public API endpoint validates its request body against a Zod schema before any logic runs; mismatches return a 400 with no further processing. User-facing validators (e.g. email format) use linear, backtracking-safe patterns to avoid regular-expression denial-of-service.
• CSRF protection: the GitHub OAuth flow rotates a single-use CSRF token via HttpOnly cookie. Stripe checkout calls use session authentication; no cross-site form posts are accepted.
• Rate limiting: the public playground (/api/try) enforces a per-IP quota (5 / hour, 2 / minute, hashed IP). Login is throttled per-IP and per-identifier (DB-backed, checked before any expensive work); sign-up, magic-link requests, and password-reset requests are throttled to prevent email bombing and mass-account creation. Authenticated APIs are additionally gated by monthly plan quota.
• Dependency scanning: GitHub Dependabot is enabled against our main repository. Vulnerable dependencies generate PRs we triage within one business day for high severity.
• Secret management: secrets live in the platform’s encrypted environment variables, injected at runtime and never committed to git. Stripe keys, the webhook secret, the email API key, and the token-encryption key are never logged.
• Security headers: HSTS (2-year, preload), X-Frame-Options: DENY,X-Content-Type-Options: nosniff, a strict referrer policy, and a restrictive permissions policy are served on every response.
• Isolation & availability: the CPU-bound obfuscation engine runs in a pool of worker threads, so a large job can never stall the main event loop or make the service unresponsive to other users.
• Change management: every code change is in git history with author + timestamp. our platform deploys automatically from the connected repository on each push; database migrations run as a pre-deploy step and abort the release on failure.
• Backups: PostgreSQL is continuously backed up with point-in-time recovery, complemented by periodic off-site logical dumps we control. Restore procedures are documented and have been tested end-to-end.

Infrastructure

Shield runs on AWS infrastructure through a managed platform that is SOC 2 Type II certified; AWS holds ISO 27001, SOC 1/2/3 and more. These are our providers’ certifications (see the note under Compliance). The stack:

Single-region by design: we run in one region for predictable latency and a simpler footprint. Multi-region failover is on the Enterprise-tier roadmap.

Subprocessors

These are the third-party services Shield uses to operate. Each is a tier-1 vendor with their own current compliance attestations:

We do not use an analytics provider or a CRM. If we add a new subprocessor, this list will be updated and any change communicated to existing customers with 30 days’ notice.

Compliance & certifications

We are transparent about where we are in the formal compliance lifecycle. Our security posture is mature; formal attestations are an ongoing investment.

If your organization requires a specific compliance artifact to evaluate Shield, please contact contact sales with the requirement and timeline.

Incident response

We follow a documented incident response process. The abbreviated version:

1. Detect. Through monitoring, vulnerability disclosure, or customer report.
2. Triage. Within one business hour of detection, classify severity (P0 — service down or data exposure; P1 — degraded; P2 — non-urgent).
3. Contain. P0 / P1 incidents trigger immediate mitigation (block, rotate, take offline). Where customer credentials may be involved, we invalidate sessions.
4. Eradicate & recover. Apply fix, restore service, validate.
5. Notify. Affected customers receive direct email notification within 72 hours of incident confirmation. If the incident involves unauthorized access to personal data, we notify regulators where required by GDPR / CCPA.
6. Post-mortem. A blameless post-mortem within 14 days of closure, with action items tracked to completion.

Report a vulnerability

We welcome coordinated vulnerability disclosure. If you believe you’ve found a security issue in Shield, please contact us before publishing or sharing details:

Out of scope

• Reports purely about missing security headers on marketing pages
• Self-XSS that requires the victim to paste hostile code into their own console
• Social engineering of Shield staff
• DoS / volumetric attacks
• Findings on third-party services (report those to the relevant vendor)
• Theoretical concerns without a reproducible exploit

We do not currently offer a paid bug bounty. We acknowledge publicly and credit researchers who help us in good faith.

Shared responsibilities

Security is a shared-responsibility model. The table below lists what we do and what we expect you to do.