Security & Privacy Practices

Workspace isolation

Every QR code, document, submission and setting belongs to exactly one workspace. Every server-side read and write checks that the requesting account actually owns the workspace it's asking about — a request for someone else's record is refused and reported identically to a request for a record that doesn't exist at all, so the two can't be told apart from the outside.

No direct database access from the browser

The browser never writes directly to Scansational's database. Every change goes through a server-side endpoint that validates the request, checks who's asking and what they're allowed to do, then writes on their behalf. Client-side checks exist for a responsive interface, never as the actual security boundary.

Account security

Sign-in is handled by Firebase Authentication, the same identity platform used by a wide range of production applications — Scansational never stores your password itself. Email addresses are verified before certain actions (like claiming a site-manager invite) are allowed to proceed.

Payment handling

Subscription and Lifetime QR payments are processed entirely by Stripe. Scansational never sees, transmits or stores your full card number, CVV or bank account details — that information goes directly to Stripe's own payment infrastructure.

Destination safety

When a dynamic QR code's destination is set or changed, it's checked against lists of known malicious and deceptive URLs, along with structural rules that catch suspicious links. A flagged destination is held for review rather than activated. This is an automated safety check, not a guarantee that every possible destination is safe — treat it as one layer of protection, not the only one.

Public forms — anonymous by design

Equipment fault reports, feedback submissions, and visitor/site sign-in all work without requiring the person scanning to create an account or identify themselves, unless the workspace owner has deliberately chosen to require contact details. These public endpoints are rate-limited to reduce automated abuse, and any photo upload is validated both by its declared type and by inspecting the actual file bytes — a file claiming to be an image but containing something else is rejected before it's ever stored.

Data minimization

Scansational does not permanently store the IP addresses of people who scan your QR codes. Unique-visitor counts use a rotating, privacy-preserving hash that can't be reversed back to an IP address. Static QR codes (including Wi-Fi passwords and vCard details) are generated entirely in your browser and never reach Scansational's servers at all.

Accounts, dynamic codes and uploaded files are stored on Google Cloud (Firebase) in the United States. Uploaded files sit in a private storage bucket that can't be read directly from the internet. Files you publish behind a QR code (such as a PDF menu) are served through Scansational using unguessable links; private business files (job photos, inspection evidence) are only shown to signed-in members of your workspace.

Where this is heading

Scansational does not currently hold a formal security certification such as SOC 2 or ISO 27001, and this page makes no claim that it does. Security and privacy practices are reviewed and strengthened on an ongoing basis as the product grows — this page will be updated if that changes in a way worth telling you about.

Reporting a concern

If you believe you've found a security issue or a QR code being used abusively, please report it or contact support@scansational.com. Our machine-readable security contact is published at /.well-known/security.txt. For how Scansational collects and uses personal information more broadly, see the full Privacy Policy.