Security Overview

1. Approach

LaunchFaro is run by a small team on a single server. We describe the controls that exist and, just as clearly, the ones that do not, so you can judge the risk for yourself. We do not claim a certification we do not hold.

2. What is in place

• Connections. The service is served over HTTPS. Responses carry a content security policy, a ban on framing, a no-sniff header, a strict referrer policy and a restrictive permissions policy.
• Sessions and tokens. Anonymous session secrets, claim links and resume links are long random values. We store only a one-way hash of each, links are single use, expire, lock after repeated wrong attempts, and are rate limited.
• Staff access. The staff area needs a secret token or a session derived from it, compared in constant time, with lock-out after 10 failures in 15 minutes. Staff actions are recorded in an audit log.
• Tenant separation. Every campaign record is tied to its owner, and queries are scoped to that owner.
• Directory credentials. A password the Service generates for a directory account is kept in a restricted file on the server, never in the database, logs or reports.
• Outbound requests. The Service refuses to fetch internal or private addresses, follows redirects only after checking each hop, respects robots.txt and fetches at most one page per second from a host.
• Hand-over. Captchas and challenges are never bypassed; the task goes to you.
• Audit trail. Campaign events are append-only: they cannot be edited or deleted through the application.
• Abuse limits. Public write endpoints are rate limited.
• Minimal third parties. No analytics, advertising or error-tracking service sees your data. Payment details go to the payment provider and never reach our servers.

3. What is not in place

We do not hold SOC 2 or ISO 27001 certification. We have not had an independent penetration test yet. The application does not itself encrypt the database or the credential file at rest; protection relies on the server and its disk. Sign-in has no second factor. There is no bug-bounty programme and no uptime guarantee, and we run on one server rather than several regions. Rate limits are per process.

4. Data location and backups

Where the server is, and which provider holds backups, are listed on the Subprocessors page. Backups roll off on the schedule in the Privacy Policy.

5. Reporting a vulnerability

Write to [to be completed: operator.securityEmail] with what you found, how to reproduce it and the impact. We acknowledge a report within 3 business days, keep you informed, and credit you if you wish.

Please do not access other people's data, degrade the service, run automated scanners that generate heavy traffic, or disclose publicly before we have had a reasonable time to fix the issue. We do not take legal action against good-faith research that follows these rules. [The lawyer must confirm this safe-harbour wording.]

6. If something goes wrong

If a breach affects your data, we tell you without undue delay and the authorities where the law requires. See the Privacy Policy.