Vulnerability Disclosure Policy

1. Our commitment

We are committed to:

• Responding promptly to good-faith reports;
• Investigating every report seriously;
• Fixing confirmed issues within a timeframe proportionate to severity (see §6);
• Crediting researchers who want public recognition;
• Not pursuing legal action against researchers who follow this policy in good faith.

2. In scope

The following systems are in scope for testing:

• elite-software.co.uk — the storefront, account area, business portal and APIs.
• elite.charity — the Shop API, Admin API and admin UI.
• license-dock.com — the LicenseDock storefront (operated by the same group).
• Any subdomain of the above to which we have intentionally exposed a service.

Eligible vulnerability classes include (but are not limited to):

• Authentication or session-management flaws;
• Authorisation bypass / IDOR;
• Server-side injection (SQL, command, template, SSRF);
• Cross-site scripting (stored, reflected, DOM) with a realistic attack scenario;
• Sensitive-data exposure;
• Payment-flow logic flaws (price manipulation, order tampering);
• Privilege escalation in the admin UI;
• Critical misconfigurations, exposed secrets, or supply-chain compromise of our published assets.

3. Out of scope

The following are not in scope:

• Denial-of-service tests (network or application) — do not run them.
• Brute-force / credential-stuffing attacks against live accounts.
• Social engineering of staff, suppliers or customers (phishing, vishing, pretexting).
• Physical attacks against our offices or staff.
• Pure best-practice findings without a concrete impact: missing security headers in isolation, weak cipher suites where TLS 1.2+ is enforced, lack of SPF/DKIM on a non-mail domain, autocomplete on forms, etc.
• Email-spoofing reports that don't demonstrate a deliverable impact.
• Findings in third-party services (Stripe, Cloudflare, Microsoft, etc.) — please report those to the relevant vendor.
• Self-XSS or attacks that require the user to paste content into the developer console.
• Software-version disclosures without an associated exploitable vulnerability.
• Vulnerabilities in unpatched browsers older than the current and previous major versions.

4. Rules of engagement

When testing in-scope systems, please:

• Stop and report as soon as you have reasonable proof of an issue — do not exploit further than necessary;
• Use only your own test accounts (or your own data) — do not access, modify or delete data belonging to other users;
• Do not exfiltrate data beyond the minimum required to demonstrate the vulnerability;
• Do not deface, drop or modify our content, or break functionality for other users;
• Do not run automated scanners at a rate that affects service availability — keep it gentle;
• Comply with the Computer Misuse Act 1990 and other applicable law;
• Treat anything you find as confidential — do not disclose it publicly until we have had a reasonable opportunity to fix.

5. Safe harbour

If you make a good-faith effort to comply with this policy during your security research:

• We will not initiate legal action against you under the Computer Misuse Act 1990, the Data Protection Act 2018, or our terms of service;
• We will tell our hosting and email providers that your activity was authorised, if it is reported to them;
• We will work with you in good faith to resolve any incidental issues caused by the testing.

We cannot, however, waive the rights of third parties. If your research could affect a third-party service, please contact us first so we can coordinate or steer you away.

6. Response and remediation timelines

From the moment a valid report reaches us we aim to:

We will keep you updated through the lifecycle. If we cannot fix within the target window we will explain why and agree a revised timeline with you.

7. Coordinated disclosure

We follow a 90-day coordinated-disclosure model by default. After that period (or earlier if we agree), you are free to publish your findings. We may ask for a short extension for critical issues that require complex remediation; we will never use this provision to delay disclosure of an actively-exploited vulnerability.

We do not operate a paid bug-bounty programme. Public recognition and a thank-you note are the recognition we offer. We acknowledge eligible researchers on our hall-of-fame page on request.

8. What to include in a report

To help us triage quickly, please include:

• A clear summary of the issue;
• The URL(s) and endpoints affected;
• Step-by-step reproduction (with any test accounts you used);
• Any proof-of-concept (request / response, screenshot, video) — keep payloads minimal;
• Your assessment of impact and CVSS 3.1 score if you have one;
• The browser / tool / version used;
• Your preferred name for any public acknowledgement (or “please keep me anonymous”).

9. Encryption (PGP)

If you need to send sensitive content, encrypt it to our security key, published at /.well-known/security.txt.

10. Acknowledgement & hall of fame

We thank security researchers publicly with their consent. If you'd like to be listed, tell us when you report and we'll add you when the issue is fixed.

11. Contact

security@eliteenterprisesoftware.com · postal: HULO Global Limited, Unit A, 82 James Carter Road, Mildenhall, United Kingdom, IP28 7DE.