We welcome reports from security researchers acting in good faith. This page explains what is in scope, what kind of testing is permitted, what is off-limits, how to contact us, and the safe-harbor commitment we make to researchers who follow the rules below.
1. In-scope domains
oraclememorizer.com and www.oraclememorizer.com — the OracleMemorizer Bible memorization app (Flutter web), including its Firebase Realtime Database and Firebase Authentication endpoints in the oracle-memorizer Firebase project.spookygengar.com and www.spookygengar.com — the SpookyGengar static website.
2. Out of scope
- Third-party services we depend on (Google / Firebase, Cloudflare, Bluehost, Google Play, App Store, Google Analytics). Report those directly to the vendor.
- Subdomains or hostnames not listed above.
- Social-engineering or physical attacks against employees, contractors, or contributors.
- Anything covered by the "What is not permitted" section below.
3. Permitted good-faith testing
- Manual probing of public endpoints for common web vulnerabilities (XSS, CSRF, IDOR, broken access control, insecure direct object references, etc.).
- Testing Firebase Realtime Database rules using your own test account — verify that other users' data is not accessible to you.
- Testing authentication, password reset, account recovery, and session flows using your own account.
- Reviewing the public Flutter web bundle for client-side issues.
- Inspecting HTTP headers, TLS configuration, DNS records, and other public signals.
4. What is not permitted
- No denial-of-service or distributed-denial-of-service testing of any kind, including volumetric, application-layer, or resource-exhaustion attacks.
- No social engineering — do not phish, impersonate, or otherwise manipulate staff, contractors, users, or third-party providers.
- No accessing, modifying, exfiltrating, or destroying data belonging to other users. If you discover access to other users' data, stop immediately, do not download or read further than necessary to confirm the issue, and report it.
- No service degradation. Stop if testing materially affects availability for others.
- No automated scanning that creates load. High-rate scanners, brute-force tooling, fuzzers run at scale, and bulk crawlers are prohibited against in-scope targets. Limit yourself to manual or low-rate probing.
- No physical attacks against infrastructure, devices, or staff.
- No spam, defacement, or destructive testing.
- Do not publicly disclose a finding (full or partial) before we have had a reasonable chance to remediate. See coordinated-disclosure timing below.
5. How to report
Send your report to [email protected].
Please include, where reasonably possible:
- A clear description of the vulnerability and where it occurs.
- Reproduction steps (URL, HTTP request, payload, screenshots, or short video).
- The impact you believe it has.
- Any suggested remediation (welcome, not required).
- Whether you would like to be credited if the issue is confirmed.
6. Response timeline
- Acknowledgement: within 5 business days of receipt.
- Initial assessment / triage: within 10 business days, including severity classification and an indicative remediation window.
- Coordinated disclosure: we ask researchers to wait until a fix has shipped or 90 days from acknowledgement (whichever is earlier) before any public disclosure. We will work with you in good faith if more time is genuinely needed for a high-impact fix.
7. Safe harbor
We will not pursue legal action against researchers who:
- Make a good-faith effort to comply with this policy;
- Avoid privacy violations, destruction of data, and disruption to our service or users;
- Report findings to
[email protected] in a timely manner; and
- Do not exploit the issue beyond what is necessary to confirm it.
If a third party (e.g. our hosting provider, a CDN, or Google) initiates legal action against you for activities that complied with this policy, we will take reasonable steps to make clear that the activities were authorized under this policy.
If you are uncertain whether a planned action falls within this policy, write to us first at [email protected] and we will tell you.
8. Bounty
We do not currently operate a paid bug bounty. We do offer public credit (with your consent) for confirmed reports.
9. Changes to this policy
Material changes will update the "Effective" date at the top. The previous version remains binding for reports made under it.
← Back to OracleMemorizer