1. Why this policy exists
Security researchers — independent or institutional — find and report defects we wouldn't catch on our own. Industry guidance from NCSC (the UK's National Cyber Security Centre), ISO/IEC 29147:2018, and RFC 9116 says every organisation should publish a clear channel for those reports — so researchers know who to contact, what's in scope, and that they won't be threatened with legal action for helping. This page is that channel.
2. Scope — what's in
ukwebmarketing.comand all sub-paths (including/api/*endpoints and any tools we host).- Client sites we operate — where the issue affects code or configuration we wrote, not the client's own content or content workflow. (If you're not sure which it is, report it anyway and we'll triage.)
- Our infrastructure as deployed — Vercel project configuration, DNS records, email routing, transactional templates.
3. Scope — what's out
Out of scope (please don't test these, and we won't accept reports about them):
- Denial-of-service (volumetric, slowloris, application-layer flooding). Vercel handles platform-level DDoS; testing it generates noise and costs us money.
- Social engineering against staff, clients, or sub-processors. Phishing test attempts will not be rewarded and may be reported to law enforcement.
- Physical attacks against any premises.
- Brute-forcing login forms or rate-limited endpoints to demonstrate that rate-limiting exists.
- Findings on third-party services we use as sub-processors (Stripe, Vercel, Cloudflare, Resend, Capsule, Plausible, Plain, Proton Mail) — please report directly to that vendor's security team. Their disclosure programmes are linked from their respective
security.txtfiles. - Self-XSS, missing best-practice headers without a demonstrable impact (e.g. "no
X-Frame-Options" on a page with no auth), SPF / DKIM / DMARC posture without a working exploit, tab-nabbing on plain external links, or banner-grabbing on standard public services. Reports of these typically get a polite "thanks, won't fix" reply.
4. How to report
Email hello@ukwebmarketing.com with the subject "Security vulnerability report". Please include:
- A description of the issue and where it is (URL, parameter, request).
- Steps to reproduce — ideally a curl/HTTP request or short script. A short video is fine if static steps don't capture it.
- Your assessment of impact — what an attacker could do.
- How you'd like to be credited (your name, handle, or "anonymous"). Credit is given by default on the fixed-issue notes unless you tell us otherwise.
- If the report contains anything sensitive, you can encrypt the body with the PGP key linked from
/.well-known/security.txt.
5. Our response SLA
| Step | Target |
|---|---|
| Acknowledge receipt | Within 72 hours |
| Initial triage (in/out of scope, severity) | Within 10 working days |
| Fix or mitigation for a critical issue (e.g. CVSS ≥ 9.0) | Within 30 days |
| Fix for a high/medium issue | Within 90 days |
| Public disclosure (where appropriate) | Coordinated with you, after the fix lands or 90 days from triage — whichever is sooner |
6. Safe harbour
If you make a good-faith effort to comply with this policy — that is, you stay within the scope above, don't access or alter more data than necessary to demonstrate the issue, don't disrupt services, don't publish the issue before we've had a chance to fix it, and tell us promptly — we will:
- Not pursue legal action against you under the Computer Misuse Act 1990 or any equivalent law for the testing activity covered by this policy;
- Not refer the matter to law enforcement for the testing activity;
- Work with you to understand and fix the issue, and credit you publicly if you'd like that.
This safe harbour applies only to UK Web Marketing's own assets. We can't grant safe harbour for testing against client sites without their prior consent — please confine testing to ukwebmarketing.com unless you have written agreement otherwise.
7. What we won't do
- We don't run a paid bug-bounty programme at this time. Credit and a thank-you, yes; cash, no.
- We don't accept reports via WhatsApp, social media DM, or the public contact form — please use the security email so it routes correctly.
- We won't share your identity with anyone outside the response team without your consent (unless we are required by law to do so).
8. RFC 9116 security.txt
The machine-readable equivalent of this policy lives at /.well-known/security.txt, following RFC 9116. It lists the contact, encryption key, preferred languages, the canonical URL of this page, and the expiry of the file itself. Automated scanners and disclosure platforms will pick it up.
9. Related documents
Data Processing Agreement (breach notification — DPA §11) · Privacy Policy · Sub-processors · All legal documents
10. Changelog
- v1.0 — 2026-06-03 — initial publication. Pairs with
/.well-known/security.txt.