Security Disclosure Policy

Sun☉Rah takes security seriously. If you believe you've found a vulnerability that affects Sun☉Rah users or infrastructure, we'd like to hear about it before disclosure becomes public, so we can investigate and fix it.

How to report

Email [email protected] with as much detail as you can share. Useful things to include:

• The URL, endpoint, or component affected
• Steps to reproduce (the more concrete, the faster we can triage)
• What an attacker could do with the issue, and any limits you've observed
• Your preferred name or handle if you'd like credit when we publish a fix

If a finding is especially sensitive and you'd prefer encrypted communication, ask in your initial email and we'll arrange a key exchange.

What to expect

• Acknowledgmentwithin 72 hours of your report. If you don't hear back, please follow up — your mail may have been filtered.
• Triage update within 7 days, including our initial severity assessment and a rough timeline for the fix.
• Coordinated disclosure: we'll work with you on the timing of public disclosure once a fix is shipped. Standard window is 90 days from the initial report, with extensions for complex issues.
• Credit: with your permission, we'll acknowledge your contribution in the relevant commit message and any post-incident write-up.

Scope

The following are in scope:

• The Sun☉Rah web application (sunrah.io and any active subdomains)
• The Sun☉Rah Pattern Engine
• Authentication, session handling, and account-management flows
• Data-handling paths involving user-supplied birth data or payment info
• Server API routes, including the city-search endpoint (/api/locations/search) and its rate limiting and input validation

The following are out of scopeand we'd prefer you not include them in your report:

• Reports generated solely by automated scanners with no demonstrated impact (we run our own scanners)
• Issues in third-party services we don't control (PayPal's checkout, Spotify embed players, Acast podcast players) — report those to the vendor
• Best-practice findings that don't have an exploitable scenario (e.g., “Header X-Frame-Options could be SAMEORIGIN instead of DENY” with no attack path)
• Denial-of-service via traffic volume (we have rate limits; please don't test them against production)
• Social engineering of staff, contractors, or users
• Physical attacks on our offices or hardware

Safe harbor

We will not pursue legal action against researchers who:

• Test only against accounts they own, or with explicit permission from the owner
• Avoid privacy violations, destruction of data, or interruption of service
• Give us a reasonable time to investigate and fix before any public disclosure
• Don't exploit beyond what's needed to demonstrate the vulnerability

This isn't legal advice and doesn't constitute a contract. If you have any doubt about whether your testing is in scope, ask first via [email protected].

Machine-readable index

A machine-readable version of this policy lives at /.well-known/security.txt per RFC 9116.