Security

1. How we protect data

• Encrypted connections: the site is served over HTTPS and sends an HTTP Strict Transport Security (HSTS) header with a two-year lifetime, subdomains included.
• Browser protections: responses carry a Content Security Policy on the main site, plus X-Content-Type-Options, X-Frame-Options, a strict referrer policy and a Permissions Policy that turns off camera, microphone and location access.
• Sign-in: accounts use Supabase Auth, which we run ourselves on our own servers. You can sign in with a password, an emailed link, GitHub or Google. Passwords are stored hashed, never in plain text. Access to your data is limited by row-level access rules in the database.
• Payments: card details are entered on Stripe's checkout and never reach our servers. We keep a plan, subscription status and a Stripe customer ID. Payment events from Stripe are checked against Stripe's signature before we act on them.
• API keys: keys for the MCP server and Pro API are signed with a server-side secret and checked on every request. Requests are logged with the key identifier, never the key.
• Rate limits: checkout, contact, Creator Program, AI generation, MCP and API endpoints have per-address or per-account limits to slow abuse.
• Secrets: service keys and tokens are kept in server environment settings, not in the code or in what is sent to your browser.
• Hosting: the application and database run on servers we operate at Hetzner in Germany and Finland. See Subprocessors.
• Less data by design: analytics are cookie-free, server logs are kept for up to 30 days, and Brand Studio AI images stay on our servers for about two hours. The Privacy Policy has the full list of retention periods.
• Limited admin access: admin tools are restricted to staff accounts, and admin actions are written to a log.

No system is perfectly secure, and we cannot promise that nothing will ever go wrong. If a breach affects your personal information, we will tell you and regulators as the law requires, as the Privacy Policy says. You can help by using a unique password, keeping your API keys private and telling us if you think a key has leaked.

2. Report a vulnerability

If you believe you found a security problem in AnimatedWebs, please tell us before you tell anyone else.

• Email hello@animatedwebs.com, or use the contact form with the topic “Security report”.
• Our machine-readable contact details are in /.well-known/security.txt.
• Include what you found, the address or endpoint, the steps to reproduce it, and the impact you think it has. Screenshots and short proof-of-concept requests help.
• Please do not include other people's personal data in your report beyond what is needed to show the problem.

What to expect: we aim to confirm that we received your report within 3 business days, keep you updated while we investigate, and fix confirmed problems as quickly as their severity allows. We ask that you give us a reasonable time to fix a problem before you share details publicly. If you want credit, tell us and, once the problem is fixed, we will thank you by name if you agree.

No bounty: we do not run a bug bounty program and do not promise payment or rewards for reports.

3. Safe harbor for good-faith research

We want researchers to feel safe reporting problems. If you follow this policy in good faith, we will not start legal action against you and will not ask a law enforcement agency to investigate you for your research on AnimatedWebs. Good faith means that you:

• test only your own accounts, or accounts whose owners agreed, and do not access, change, copy or delete other people's data beyond the minimum needed to show the problem;
• stop and report if you reach personal data, and do not keep or share it;
• do not run denial-of-service tests, flood our endpoints, send spam, or use social engineering or physical attacks against our staff, users or providers;
• do not degrade the service for other users, and do not test the systems of our providers (Stripe, hosting and others), which have their own rules;
• report promptly and give us a reasonable time to respond before any public disclosure.

This safe harbor covers our own systems only. It does not bind third parties, and we cannot waive claims that belong to others. If a third party starts action against you for research done under this policy, tell us and we will say that you acted in good faith. Reports about activity that breaks this policy may not be covered.

4. Out of scope

• Findings that need a rooted device, a stolen session or physical access.
• Missing best-practice headers or settings with no demonstrated impact, and reports from automated scanners with no proof of an actual problem.
• The live demos under /demos that are static previews of templates and hold no user data, unless the problem affects the main site.
• Problems in third-party services we link to or use. Please report those to the service itself.

5. Related

Privacy Policy · Subprocessors · Acceptable Use Policy · All policies