Vulnerability Disclosure Policy

RATEPULSE LTD · v1.0 · Effective 2026-08-25

RATEPULSE LTD (company number 17408208) operates the RatePulse platform at ratepulse.io. We would rather hear about a security problem from you than find out about it from an incident.

This policy explains how to report one, what we will do, and what we ask of you in return. It is a disclosure policy, not a paid bug bounty — we do not currently offer rewards, and we say so up front rather than leaving it implied.

1. How to report

Email security@ratepulse.io.

Please include enough for us to reproduce the issue: the affected URL or endpoint, the steps, what you expected and what happened instead, and any proof-of-concept. Screenshots or a short recording help. Report in English.

If the finding involves personal data, tell us what you saw but do not send us copies of other people’s data. A description and a count are enough.

2. What we will do

• Acknowledge within 3 working days. A human, not an autoresponder.
• Assess and come back within 10 working days with our view of severity and what we intend to do.
• Keep you updated while we fix it, and tell you when it is fixed.
• Credit you in our disclosure record if you want to be named. Equally, we will keep you anonymous if you prefer.

We will not ask you to sign a non-disclosure agreement as a condition of reporting, and we will not use one to keep a finding quiet.

3. What we ask of you

• Give us reasonable time to fix it before going public. 90 days is our default expectation, and we will usually be much faster. If you think the risk to users justifies a shorter window, say so and we will discuss it rather than argue about it afterwards.
• Do not access, modify or delete data that is not yours. If you find a way into another customer’s data, stop at the point where you have proved it and tell us.
• Do not degrade the service. No denial-of-service, no volumetric load testing, no spam or social engineering of our staff, customers or their guests.
• Use your own test account wherever possible. Ask us and we will provide one.
• Stay within our systems. Our sub-processors — the payment provider, the cloud platform, the email services, the property management systems our customers connect — are out of scope. Report those to them.

4. Our commitment to you

If you act in good faith and follow this policy, we will not pursue legal action against you, and we will not report you to law enforcement for your research. We consider your work authorised for the purposes of the Computer Misuse Act 1990 and equivalent legislation.

If a third party brings action against you for activity conducted in accordance with this policy, we will make it known that your actions were authorised.

This protection is about conduct, not intent alone: accessing data beyond what is needed to demonstrate a finding, or exploiting an issue for gain, falls outside it.

5. Scope

In scope

• ratepulse.io and its subdomains
• The REST API beneath /api/
• The hosted widgets and pages we serve on behalf of customers: the booking page at /p/, the unsubscribe route at /u/, and the tag, diverter, concierge and booking scripts

Out of scope

• Third-party services we use rather than operate — the cloud platform, the payment provider, email delivery, error monitoring, electronic signature, and any property management system a customer connects
• Our customers’ own websites, even where one of our scripts runs on them
• Denial-of-service, volumetric testing, and physical or social engineering
• Findings that rely on a compromised end-user device, or on a browser or operating system that is no longer supported by its vendor
• Reports produced solely by an automated scanner with no demonstrated impact. We read them, but a missing header with no exploitation path will be triaged as informational

6. Things we already know

Reporting these is welcome but they are not new to us:

• The Content-Security-Policy is deployed in report-only mode and requires 'unsafe-inline' and 'unsafe-eval' on script-src for the authentication library we use. Deliberate, documented, and being worked on.
• HTTP compression is enabled. We do not use cookie-based sessions, which is what makes the theoretical attack against it impractical here.
• The public widget configuration endpoints issue a per-day token that is not a secret. It exists to raise the cost of casual abuse alongside rate limiting and an origin allowlist, not to authenticate anyone.

7. Contact

security@ratepulse.io — security reports and this policy privacy@ratepulse.io — data protection and personal data enquiries

Machine-readable contact details: /.well-known/security.txt

RATEPULSE LTD, 176 Mytchett Road, Mytchett, Camberley, England GU16 6AE.