In short
- The free check accepts only public web URLs and uses strict size, time, redirect, port and rate limits.
- Business checkout, confirmation and order-status records are stored in an EU-jurisdiction D1 database; payment credentials never enter Staedy.
- The Worker creates one-off Mollie payments directly and verifies each webhook against Mollie's API before marking an order paid.
- Unpaid checkout orders are deleted automatically after 90 days; paid records follow contract and accounting retention.
- Report vulnerabilities to security@staedy.com.
1. Bounded public check
The check accepts HTTP and HTTPS public business websites only. It rejects credentials in URLs, localhost and internal names, literal IP addresses and non-standard ports. Fetches are capped by time, response bytes and redirect count and stay on a small, same-origin page sample.
Browser request bodies are size-limited, and the check and order-creation endpoints use IP-based Cloudflare rate limiting. Payment-status lookups use unguessable order references. The Worker returns neutral errors and no-store responses.
2. AI safety and factual control
Sampled website content is treated as untrusted evidence. The system prompt tells the model not to follow instructions contained in the website and to use only explicit facts or strongly supported themes. Output is schema-checked and rejected when incomplete or unsupported; deterministic fallbacks are used where appropriate.
The free result is labelled automatically generated and preliminary. Models do not accept a contract, change the price, receive checkout or billing data, approve hotel facts or publish a website change.
3. Data minimisation and retention
The public check does not persist sampled page text or generated results in the checkout database. Operational logs omit submitted contact, company, billing, VAT and page-text data and record only limited outcome and status metadata.
The checkout database stores the fields needed to establish and administer the business order. It is restricted to Cloudflare's EU D1 jurisdiction, and a daily scheduled job deletes unpaid records older than 90 days while preserving paid contract records for the applicable project, limitation and accounting periods.
4. Browser and transport security
Cloudflare terminates HTTPS for staedy.com. Static pages send a restrictive Content Security Policy, deny framing, restrict referrer information and disable unneeded browser permissions. Scripts, styles, fonts and product images are served from Staedy's origin; runtime calls to Google Fonts and third-party logo hosts have been removed.
API responses use no-store caching, JSON content types and nosniff protection. Cross-origin API access is limited to explicit local development origins.
5. Project access and publishing
The public onboarding does not ask for passwords or platform credentials. Where an accepted project needs direct implementation, Staedy agrees a restricted access route and minimum permissions. Credentials must not be sent by ordinary email and are removed when no longer needed.
Customer changes are shown in a private preview or comparable review format. Publication requires the approval identified in the accepted scope. DNS, business email, booking-engine, checkout and destructive database changes require separate express approval.
6. Providers and secrets
Infrastructure bindings and provider credentials, including the Mollie API key, are configured as Cloudflare bindings or secrets rather than embedded in public source. The browser never receives that key. Mollie callbacks provide only a payment reference; the Worker retrieves the payment from Mollie and verifies its order reference, amount, currency and status before updating D1. The active provider list and transfer roles are published under Service providers.
7. Incident response
Suspected incidents are contained, evidence is preserved proportionately, affected data and people are assessed, and remedial steps are documented. The privacy procedure includes the Art. 33 GDPR 72-hour authority assessment and Art. 34 notification assessment for high risk to people.
8. Vulnerability reporting
Email security@staedy.com with the affected URL, impact and safe reproduction steps. Do not access, alter or delete another person's data; disrupt the service; use the finding for extortion; or publish details before a reasonable remediation opportunity.
Staedy does not currently operate a paid bug bounty. We will not pursue good-faith research that follows the boundaries above.
9. Limits of this page
This page describes current implemented controls. It is not a certification, penetration-test report or guarantee that a system can never fail. Material control changes are reflected here and in the privacy notice.