Security Disclosure

1. Our stance

We take the security of the Service seriously and welcome good-faith security research. If you find a vulnerability, tell us first, privately, and give us time to fix it before it becomes public. We will not pursue legal action against researchers who follow this policy, and we will credit you publicly if you opt in.

2. What we want to know

We are interested in vulnerabilities affecting:

• the website and customer dashboard (authentication, authorisation, session handling, CSRF, injection, IDOR, business-logic flaws)
• the license system: seat binding, key generation, activation and validation APIs, license revocation
• the payment webhook processing (signature verification, order status transitions)
• the download endpoints (path traversal, unauthorised file access, rate-limit bypass)
• the endpoint agents, insofar as a vulnerability can be demonstrated against our servers

3. Out of scope

The following are out of scope and will not qualify for credit:

• social engineering of staff or other users
• physical attacks, or denial-of-service attacks beyond modest, non-destructive testing
• automated vulnerability scans that do not demonstrate an actual impact
• theoretical issues without a working proof of concept
• issues already disclosed publicly or reported to us previously
• missing security headers, self-XSS, or cosmetic issues without security impact

4. How to report

Email security@yakiembattle.com with a subject line of "Security disclosure: <short summary>". Include:

the affected endpoint or component and the steps to reproduce, ideally with a minimal proof of concept

the impact you believe the issue has, and the severity you would assign

your name and how you would like to be credited (or that you prefer to stay anonymous)

5. What happens next

We commit to:

• acknowledging your report within 5 business days
• keeping you informed of progress as we triage and fix
• fixing issues according to severity: critical issues as soon as a validated fix is ready, others on the next release cycle
• agreeing with you before any coordinated public disclosure, typically 90 days after a fix ships

6. Safe harbour

We consider research conducted in line with this policy to be authorised. You must not access or modify data you do not own, must not run tests that impact other users, and must stop testing immediately if you encounter personal data of third parties. If you do, report it as part of your disclosure and delete the data.