Responsible Disclosure Policy
If you have found a security problem in something we run, we want to hear about it. This page explains how, and what happens next.
Scope
This policy covers systems operated by ASTRI DEVS LTD, which currently means:
- astridevs.co.uk and any subdomain of it;
- the contact endpoint at /api/contact.
Systems we built for a client but do not operate are not covered. Those belong to the client and are subject to the client's own policy. If you have found something in a system you believe we built, tell us and we will pass it to the right people — but please do not test a client's system under this policy, because we cannot authorise testing on someone else's infrastructure.
How to report
Email info@astridevs.co.uk with "Security" in the subject line. Please include:
- the URL or endpoint affected;
- a description of the issue and why you believe it is a security problem;
- the steps needed to reproduce it, and any proof-of-concept request or payload;
- anything you know about the impact.
Reports in English are easiest for us to act on quickly. If you would rather write in another language, please still send it — we would much rather have the report.
What to expect from us
- We will acknowledge your report within five working days.
- We will tell you whether we have been able to reproduce the issue, and give you an assessment, within ten working days of acknowledging it.
- We will keep you informed while we work on a fix, and tell you when it is deployed.
- We will credit you publicly if you would like us to, and will not name you if you would prefer we did not. Tell us which you want.
We do not run a bug bounty programme and we do not pay for reports. We are saying that plainly so nobody spends time on the expectation of a reward. What we offer is a prompt, honest response and credit if you want it.
What we ask of you
- Give us reasonable time to fix the issue before disclosing it publicly. Ninety days is a sensible default, and we will usually be much faster than that.
- Do not access, modify or delete data that is not yours. If you come across personal data, stop, and tell us what you found rather than collecting it.
- Do not degrade the service for other people. That rules out denial-of-service testing, large-scale automated scanning and brute-force attempts.
- Do not use social engineering, phishing or physical attacks against our people or premises.
- Keep the details of the issue confidential until it is resolved.
Out of scope
The following are unlikely to be treated as vulnerabilities. Report them anyway if you believe there is real impact and can show it — this list exists to save you time, not to dismiss you.
- Missing security headers with no demonstrated exploit.
- Reports produced entirely by an automated scanner with no verification.
- Issues requiring physical access to a device, or a compromised browser or network.
- Denial of service, volumetric attacks and rate-limit exhaustion.
- Email configuration findings such as SPF, DKIM or DMARC policy, absent a working spoof.
- Software version disclosure without an associated exploitable vulnerability.
- Self-inflicted issues that require the victim to paste an attacker's code into a console.
- Clickjacking on pages with no state-changing action.
Our commitment to researchers
If you make a good-faith effort to comply with this policy during your research, we will treat your research as authorised, we will work with you to understand and resolve the issue quickly, and we will not pursue or support legal action against you in relation to it.
If a third party brings action against you in connection with research you carried out in accordance with this policy, we will make it known that your actions were authorised by us.
If at any point you are unsure whether something is within this policy, ask us first at info@astridevs.co.uk.
security.txt
A machine-readable version of this policy is published at /.well-known/security.txt, following RFC 9116.