Security disclosure policy

Found a security issue? Email security@ondurr.com. We will respond within 5 business days and work with you to fix the issue before any public disclosure. We will not pursue legal action against good-faith research that follows this policy.

Things we want to hear about:

• Authentication bugs (account takeover, session hijack, privilege escalation)
• Authorization bugs (IDOR, accessing other users' data)
• Injection (SQL, XSS, command, header)
• Cryptographic weaknesses
• Server-side request forgery, server-side template injection
• Information disclosure (sensitive data in URLs, logs, responses)
• Insecure direct file uploads or path traversal in storage
• Sensitive data leaking across users (location, messages, photos, reports)
• Race conditions with security impact (block evasion, filter bypass)
• Weaknesses in our anti-spoof / anti-fake account defenses

Issues we already know about or don't consider security vulnerabilities. Reporting these is fine but won't get a long writeup back.

• Self-XSS that requires the victim to paste attacker code into their own DevTools
• Missing security headers without an exploit path
• Reports generated by automated scanners with no manual verification
• Lack of rate limiting on endpoints that are clearly rate limited (paste the response showing it's not, then we'll investigate)
• Username / email enumeration via signup (we deliberately allow signup to indicate “email already in use”; we don't treat that as enumeration on a public signup form)
• Open redirects on the verify / reset-password flows where the redirect target is on our own allowlist
• Issues that require physical access to the victim's unlocked device
• Denial of service that requires substantial network or compute resources
• Vulnerabilities in third-party services we depend on (Supabase, Vercel, Cloudflare, etc.) unless the bug is in how WE use them

Email security@ondurr.com with:

• A clear description of the bug
• Steps to reproduce. Concrete is better than abstract.
• The impact: what does an attacker get?
• Your handle / how you want to be credited (optional)

If the report contains sensitive data (real user info you stumbled onto, an active exploit URL, anything that should not be in plain email), tell us in the first message and we'll set up a more secure channel.

• Acknowledgment within 5 business days
• Triage status within 10 business days
• Regular updates on fix progress (every 7 days minimum on accepted reports)
• Credit in our disclosure log once the fix is live, if you want it
• No legal action against good-faith research per the safe-harbor section below

We will not initiate legal action against you for research and disclosure activity that, in good faith:

• Avoids harm to users, the platform, or other systems
• Does not access, modify, or destroy data beyond what is strictly necessary to demonstrate the bug
• Does not use techniques that would degrade service for other users (no DDoS, no resource exhaustion attacks)
• Reports the issue to us before any public disclosure
• Gives us a reasonable window (typically 90 days) to fix before public disclosure

If your research crosses a line we did not anticipate, contact us before going further. We would rather have a conversation than a surprise.

• Run a paid bounty program (yet; this may change as the platform grows)
• Pay for low-impact reports or duplicates
• Sign blanket NDAs that prevent later public disclosure
• Use legal threats to silence good-faith researchers

If you believe we have not responded appropriately or you think something is in scope that we've called out of scope, write back and tell us. We are a small team. We will read your reply and reconsider. Reasonable people can disagree on severity; we try to stay reasonable.

• /.well-known/security.txt (machine-readable contact, RFC 9116)
• Privacy notice (data subject rights, retention policy, processor list)