Skip to main content
ROOTSLY
Start

Rootsly security · v1.0.0

Report a security concern without increasing the risk.

Tell Rootsly about a suspected vulnerability, compromise or exposure through one protected route. Please minimise testing and stop before another homeowner, client or service is affected.

Operational launch validation is still required

The public route and protected incident register are implemented, but the security mailbox, named owner and response rota must be validated before a genuine public pilot. Broader safe-harbour wording also awaits professional review.

Start with security@rootsly.co.uk

This route is separate from general support, sales and privacy rights. Send a short first message without passwords, tokens, raw records or copied homeowner information.

Email the security route

Include in the first report

  • A concise description of the suspected issue, the affected Rootsly URL or feature and the security impact you believe is possible.
  • The date and UTC time observed, browser or client context and minimal numbered steps using your own account or synthetic data.
  • Whether you stopped after seeing another person's data, cross-tenant behaviour, a secret or an unexpected external effect.
  • A safe opaque evidence reference if one exists; wait for a protected exchange route before sending screenshots, traces or other sensitive material.
  • A contact method Rootsly can use for clarification and whether you want public acknowledgement considered after remediation.

Need to share sensitive evidence? Ask for a protected exchange route first. Do not place evidence in a public file host or a normal support ticket.

Scope does not equal permission to test.

Publishing a security contact and this staging policy does not grant blanket permission to scan, bypass access controls, exploit a weakness or access another person or organisation's data. Normal lawful use of your own account, passive inspection and synthetic test data remain the standing boundary; ask Rootsly in writing before any active testing beyond it.

In scope for reporting

  • Rootsly-owned pages and application routes delivered from rootsly.co.uk and official Rootsly-managed subdomains.
  • The Rootsly homeowner assessment, organisation workspace, super-admin surface, report access and six-digit-code authentication boundaries.
  • The Rootsly widget loader and the Rootsly-controlled iframe experience, excluding the host company's separate website code.
  • Tenant-isolation, role-authorisation, private-storage and short-lived access-token behaviour implemented by Rootsly.
  • Rootsly server routes, security headers and first-party operational controls visible through normal lawful use.
  • A suspected compromise, exposure or integrity problem involving data already entrusted to the Rootsly service.

Outside Rootsly's scope

  • A client company's separate website, staff, premises, email, devices, services or systems that Rootsly does not operate.
  • Vercel, Supabase, Resend, Cloudflare, Chimnie or another provider's systems and dashboards; report those through the provider's own disclosure route.
  • Third-party software, browser extensions, networks or integrations not supplied as part of the Rootsly service.
  • Guesses about a weakness without a Rootsly-specific, safely reproducible security impact.
  • Rate-limit observations, missing optional headers, self-only behaviour or version banners that do not create a credible security consequence.

Good faith is measured by the harm you avoid.

Finding something during normal lawful use is not the same as receiving permission for active security testing. These expectations make it safer to report what you saw and coordinate what happens next.

What Rootsly asks of you

  • Use only accounts, devices and data you own or are expressly authorised to test, and prefer the staging environment and synthetic data.
  • Use the minimum action needed to describe the issue; do not prove impact by accessing, changing, downloading or deleting real data.
  • Stop immediately if you encounter personal data, another tenant's material, a credential, a secret, unsafe external work or service instability.
  • Report promptly through security@rootsly.co.uk and keep the suspected issue private while Rootsly validates and coordinates a response.
  • Avoid privacy harm, service degradation, financial cost, duplicate contact, data corruption and disruption to any homeowner, client or provider.
  • Do not threaten disclosure, demand payment, create urgency or make a report conditional on a bounty, contract, testimonial or commercial benefit.
  • Provide truthful evidence, answer reasonable clarification questions and do not submit repeated automated or low-quality reports.

What Rootsly commits to

  • Rootsly will treat a genuine report respectfully, acknowledge it against the stated operational target and provide an opaque reference when triage begins.
  • Rootsly will not require a non-disclosure agreement merely to receive a report and will ask only for information reasonably needed to validate and address it.
  • Rootsly will restrict sensitive report evidence to people and providers needed for investigation, containment, legal review and remediation.
  • Rootsly will give a reasonable progress update when work takes time, without exposing exploit detail or promising an unsafe fix date.
  • Rootsly will consider a requested acknowledgement only after remediation and only with the reporter's agreement; no acknowledgement is guaranteed.
  • Broader legal safe-harbour language is not effective until professional review. Reporting an issue is encouraged, but it cannot retrospectively authorise prohibited activity or bind a third party.

Prohibited actions

Stop and report if demonstrating an issue would require any of these actions. The disclosure route does not legitimise them.

  1. 01Accessing, downloading, retaining, changing or deleting another person or organisation's data, even to demonstrate impact.
  2. 02Bypassing tenant, role, authentication, report-token, private-storage or support-access controls beyond the minimum normal-use observation.
  3. 03Denial-of-service, resource-exhaustion, high-volume scanning, load testing, spam or activity likely to impair Rootsly or a provider.
  4. 04Social engineering, phishing, vishing, credential collection, impersonation or contacting Rootsly clients, homeowners, staff or providers about the test.
  5. 05Physical testing, device access, office access, tailgating, surveillance or testing an individual's personal account or equipment.
  6. 06Introducing malware, persistence, a backdoor, destructive payload, data corruption or any technique intended to maintain access.
  7. 07Triggering a paid Chimnie request, live email, referral, lead, notification, fee event, export or other real-world effect as a security test.
  8. 08Extracting secrets, tokens, database records, report contents, detailed financial answers, source code or provider payloads.
  9. 09Testing a third-party or client-owned system under this policy, or representing that Rootsly has authorised testing of that system.
  10. 10Publicly disclosing an unresolved issue or sharing protected evidence before Rootsly has had a reasonable opportunity to validate and coordinate remediation.
  11. 11Using a suspected weakness for personal, commercial or competitive advantage, or making payment a condition of responsible reporting.

What happens after your report

A human—not an email subject or automated severity guess—routes the report into the protected incident process.

Response target

Critical security or platform failures target a same-business-day human response. Normal reports target one business day. This is an acknowledgement target, not a universal remediation deadline.

  1. 01

    The security mailbox is checked and the report is screened for phishing, unsafe attachments and immediate containment need.

  2. 02

    A human assigns the incident category and severity; an email subject or reporter claim never determines severity automatically.

  3. 03

    A confirmed or credible report receives a personal-data-minimised record in the protected Rootsly incident register and an opaque reference.

  4. 04

    Rootsly preserves bounded evidence, coordinates the affected application or provider owner and separates internal, client and public updates.

  5. 05

    Critical security or platform failures target a same-business-day human response; normal reports target one business day.

  6. 06

    Resolution timing depends on impact, reproducibility, third parties, safe remediation and legal obligations, so no universal fix deadline is promised.

  7. 07

    Rootsly closes the loop with the reporter where possible and records follow-up and post-incident review without publishing unsafe detail.

No bug bounty

Rootsly does not currently offer a bug bounty, promise payment or make a public acknowledgement automatic.

Service updates

Safe material service information appears separately on the public status page without exploit detail or client identity.

Open service status

Privacy rights are separate

Use the verified privacy route for access, correction, restriction or anonymisation review rather than sending those details here.

Privacy requests

Standards and implementation sources