Reporting a security issue

• What you found and where: the URL, page or endpoint.
• Steps to reproduce it, with requests or screenshots if you have them.
• What an attacker could do with it.
• How to reach you, and whether you’d like to be credited.

Please don’t include personal data that isn’t yours. If you came across any, tell us what kind it was rather than sending it.

• We acknowledge your report within two working days.
• We tell you whether we can reproduce it, and keep you updated while we fix it.
• We tell you when it’s fixed, and credit you if you’d like.

We won’t pursue or support legal action against research done in good faith under this policy. Good faith means you:

• test only against accounts you own or have permission to use;
• don’t access, change or keep other people’s data beyond what’s needed to show the issue;
• avoid degrading the service: no denial-of-service or high-volume automated testing;
• don’t use social engineering, phishing or physical attacks;
• give us a reasonable time to fix the issue before telling anyone else.

If you’re unsure whether something is in bounds, email us first and ask.

In scope: this website and app at dyeline.ai, including sign-in, account settings and the dashboard.

Out of scope: services we use but don’t run (our hosting, database and email providers, GitHub and Google sign-in). Please report those to the provider. Reports from automated scanners need a demonstrated impact.

• No analytics, trackers or third-party scripts; a nonce-based Content Security Policy blocks everything else.
• Passwords are hashed. New ones are checked against known data breaches using only a five-character prefix of their hash.
• Two-factor authentication and passkeys are available to every account.
• IP addresses are never stored whole: sessions keep a partial address, and abuse limits use salted hashes.

Our machine-readable contact details are in security.txt.