Security policy
A clear route for reporting vulnerabilities in XsiSec-owned systems, with practical scope, testing rules, response expectations, and optional public recognition.
- 5 days
- Acknowledgement target
- 10 days
- Triage target
Report a vulnerability
Send reports to security@xsisec.com. A useful report identifies the affected page or component, explains the security impact, and includes concise steps that reproduce the issue. Please use test accounts and data that belong to you.
Scope
This policy covers only systems and code controlled by XsiSec:
- The production website hosted at https://www.xsisec.com.
- First-party repositories and software explicitly published and maintained by XsiSec.
- Vulnerabilities with a realistic effect on confidentiality, integrity, authentication, authorization, or availability.
Hosting providers, Firebase, GitHub, package maintainers, external APIs, and other third-party services are governed by their own disclosure policies. This page does not authorize testing against those systems.
Safe harbor
XsiSec considers security research authorized when it is performed in good faith, remains within the scope and rules of this policy, and is reported promptly through the contact route above. XsiSec will not pursue legal action against a researcher for that activity.
If an issue is unclear or a test could affect real users, stop and ask before continuing. This commitment applies only to XsiSec-controlled systems and cannot bind third parties or public authorities.
Protect users and services
- Stop testing once the vulnerability has been demonstrated.
- Do not access, modify, retain, or share information that does not belong to you.
- Do not cause denial of service, resource exhaustion, destructive changes, or measurable degradation for other users.
- Do not use phishing, social engineering, credential attacks, malware, physical intrusion, or persistence mechanisms.
- Do not pivot from an XsiSec asset into a third-party environment.
- Automated scanner output must be manually verified and include a credible security impact.
What to include
- Affected URL, repository, version, or component.
- Observed behavior and expected behavior.
- Security impact and realistic attack scenario.
- Minimal reproduction steps or a small proof of concept.
- Relevant request, response, log, screenshot, or test account details.
- Your preferred name or handle for future communication.
Remove secrets and unrelated personal data before sending a report. Do not email password databases, session tokens, private keys, or full data exports when a smaller sample proves the issue.
What happens after a report
- AcknowledgementTarget: within 5 business days.
- TriageTarget: an initial scope and severity assessment within 10 business days.
- RemediationValid reports are prioritized according to impact, exploitability, dependencies, and the risk of deploying a fix.
- DisclosurePublic disclosure should be coordinated after a fix is available or after a timeline has been agreed in writing.
These are operational targets, not guarantees. XsiSec is not currently running a paid bug bounty program, and compensation should not be expected unless it has been agreed in writing.
Security acknowledgments
XsiSec may publicly thank researchers who submit a valid report, follow the disclosure policy, and help verify remediation. Recognition is optional and is published only with the researcher's permission.
No researchers are listed yet. This page will not publish names, handles, or vulnerability details without prior consent.