We take the security of our users and our infrastructure seriously. We welcome reports from the security-research community and offer good-faith researchers a documented safe-harbor commitment in exchange for following the guidelines below.
1. Reporting Channel
- Email: info@baaed.com with subject "Security Vulnerability Report".
- PGP / encryption: if you would like to send sensitive details encrypted, request our PGP key from the same address.
- security.txt: the canonical machine-readable contact is at http://baaed.com/index.php/.well-known/security.txt (RFC 9116).
Please do not file vulnerability reports through public channels (Twitter/X, GitHub issues, support chat) or to non-security email addresses.
2. What to Include in a Report
To help us triage quickly, please include:
- A clear description of the vulnerability and its impact.
- Step-by-step reproduction instructions.
- The exact URL(s) and HTTP request(s) involved.
- Any proof-of-concept payload (sanitised).
- Your assessment of severity (CVSS or DREAD score is helpful).
- Whether you are willing to be credited publicly once the issue is fixed.
3. Scope
In scope:
- baaed.com and all subdomains controlled by Baaed FREE SEO Suite.
- Our production APIs.
- Our authentication and billing flows.
- Server-side and client-side application vulnerabilities (XSS, CSRF, SSRF, IDOR, RCE, SQLi, authentication bypass, privilege escalation, etc.).
Out of scope:
- Third-party services and infrastructure we use (Cloudflare, AWS, Stripe, PayPal, Anthropic, OpenAI, etc.) — report these to the relevant vendor's security team.
- Issues caused exclusively by outdated browsers or unsupported assistive technologies.
- Theoretical issues without a demonstrable real-world security impact.
- Findings from automated scanners without manual validation and analysis.
- Self-XSS or social-engineering attacks against our staff or other users.
- Reports of missing security headers, missing best-practice features, or compliance-checklist items without concrete impact.
- Rate-limit or denial-of-service findings (we accept reports of unauthenticated DoS via small payloads, but not bulk-traffic DoS).
- Email-spoofing reports below the SPF/DKIM/DMARC level we have published.
- Subdomain-takeover reports affecting parked or unused subdomains we no longer control.
4. Rules of Engagement
While testing, you must:
- Test only against your own account or test accounts you create. Do not interact with other users' accounts or data.
- Stop and report immediately if you encounter personal data of others.
- Avoid actions that would degrade service for other users (no fuzzing production at high rate, no automated scans that exceed 5 requests/second).
- Never modify, exfiltrate, retain, or destroy data that does not belong to you.
- Not perform social-engineering attacks on our staff or contractors.
- Not use found vulnerabilities to access more data than is needed to demonstrate impact.
- Not publicly disclose the vulnerability until we confirm it is fixed (see Section 7).
5. Safe Harbor
We will not pursue civil or criminal action against good-faith security researchers who:
- Comply with this Policy and the Rules of Engagement above.
- Make a good-faith effort to avoid privacy violations, destruction of data, and interruption or degradation of the Service.
- Promptly report the vulnerability to us and give us a reasonable opportunity to fix it before public disclosure.
Activities conducted in a manner consistent with this Policy will be considered authorised conduct under the U.S. Computer Fraud and Abuse Act (CFAA), the U.K. Computer Misuse Act 1990, and the EU Directive 2013/40/EU on attacks against information systems, and we will not file a report against you with law enforcement.
This safe harbor does not extend to activities outside the scope of this Policy, including testing of third-party services.
6. Our Response Commitment
- Acknowledgement: within 3 business days of receiving your report.
- Initial triage: within 10 business days, we will provide an initial assessment of severity, in-scope status, and likely remediation timeline.
- Remediation timelines (target):
- Critical: 7 days.
- High: 30 days.
- Medium: 90 days.
- Low: best effort, within the next normal release cycle.
- Closure notification: we will let you know when the issue is resolved and, with your consent, credit you in our acknowledgements.
7. Coordinated Disclosure
We follow a coordinated disclosure model. Please give us the time set out in Section 6 to remediate before publishing details of the vulnerability. We will work with you on a mutually-agreed disclosure timeline; in extraordinary circumstances we may request a longer embargo to protect users (e.g. when a fix requires migration of stored data).
8. Bug Bounty
We do not currently operate a paid bug-bounty programme. We do offer:
- Public acknowledgement on a researchers page (with your consent).
- Swag, discount codes, or non-cash tokens of appreciation for material reports, at our discretion.
- A written letter of thanks suitable for inclusion in a CV or résumé.
9. What We Will Not Do
- We will not file a complaint against you with law enforcement for activities consistent with this Policy.
- We will not require you to sign an NDA as a condition of accepting your report (you may, however, choose to disclose under embargo).
- We will not retaliate against researchers who follow this Policy in good faith.
10. Acknowledged Researchers
With consent, researchers who have contributed material vulnerability reports are credited at http://baaed.com/index.php/security-policy#hall-of-fame (page hash, when published).
11. Hall of Fame
Coming soon. If you are the first researcher to report a valid vulnerability, your name will go here.
12. Updates
We may update this Policy periodically. Material changes are announced on this page. The "Last updated" date is the authoritative version marker.
13. Contact
Security team: info@baaed.com