Security

1. How the site is built

The site is plain HTML, CSS and JavaScript, hosted on Vercel. There is no content management system, no admin login and no build step.

• HTTPS everywhere. Vercel serves the site over HTTPS and manages the certificates. It also sends an HSTS header, which tells browsers to refuse plain HTTP connections to the site.
• No user accounts. There is nothing to log in to, so there are no passwords for us to store or lose.
• No payments. The site does not take payments or handle card details.
• No visitor database. We do not run a database of visitor data. The readiness check keeps nothing after it answers.
• Few third parties. The only third-party script on the site is Google Analytics. Fonts are hosted on the site itself. "Book a call" links open Calendly in a new tab and are not embedded in our pages.

2. Forms and the data you send

Forms on the site are sent over HTTPS to Formspree, a form-handling service, which forwards them to our email inbox. They are not stored on this website.

Each form has a hidden field that people never see. If a bot fills it in, the submission is dropped.

Please do not send passwords, access keys or other secrets through a form or by email. If we need access to a client system, we agree how to do that with the client directly.

The Privacy policy lists every provider that handles personal data for us.

3. The free readiness check

The check is the only part of the site that runs code on a server. You give it a URL. A Vercel serverless function fetches that page, plus the same site's /robots.txt and /llms.txt, analyzes them in memory and returns a score.

A tool that fetches any URL a stranger types is an obvious target. People could try to point it at private systems. These are the rules the function enforces.

What it will and will not fetch

• Public web addresses only. It accepts http and https URLs on the standard web ports, 80 and 443. URLs that contain a username or password are refused.
• Private and reserved ranges are blocked. That covers loopback, private networks, link-local addresses (including cloud metadata addresses), carrier-grade NAT, documentation and multicast ranges, in both IPv4 and IPv6. Internal-style host names such as localhost and .local are refused as well.
• Every DNS answer is checked. The function resolves the host name first. If any address it resolves to is private or reserved, the request is refused. The same check runs again at the moment of connection, so a host cannot pass the check and then switch to an internal address.
• Redirects are re-validated. It follows at most three redirects, and every hop goes through all the same rules.
• Read only. It sends plain GET requests, with no cookies and no credentials. It does not submit forms or run the page's JavaScript.

Limits

• Time. The page fetch is cut off after 8 seconds. The two text files are cut off after 6 seconds. The whole function stops at 15 seconds.
• Size. It reads at most 6 MB of the page and 300 KB of each text file. Size is counted after decompression, so a small compressed file cannot expand into a huge one.
• Rate. 10 checks per minute per IP address. The counter lives in memory on each server instance, so treat it as best effort and not an exact quota.
• Origin. Browsers may only call the function from this website. Requests from pages on other sites are refused.

What happens to the fetched content

• It is never shown to anyone else. The fetched HTML stays inside the function. Only derived facts are returned: the score, the check results and short extracted values such as the product name and price.
• Those short values are length-limited and stripped of control characters and angle brackets. Your browser then displays them as plain text, never as HTML.
• Nothing is stored. The function has no database and writes no files. Responses are marked so they are not cached. Our code logs only unexpected internal errors.
• The function uses only what is built into Node.js. It has no third-party packages.

How it identifies itself

The check sends this User-Agent with every request: RecommendedByAgentsCheck/1.0 (+https://www.recommendedbyagents.com/). If you run a site and would rather it was not checked, block that User-Agent or email us.

Please only submit URLs of public pages. The Terms set out the rules for using the tool.

4. How we handle client work

Our services change code on client stores, so this matters more than the website does. How we work is described on the About and What we do pages. In short:

• Changes arrive as pull requests or theme changes, on the platform the client already uses.
• Nothing ships without the client team's review. They know the store, and they keep control of it.
• We leave documentation the client's team can maintain.

Access, confidentiality and data handling for each engagement are set out in the written agreement with that client.

5. What we do not claim

We are a small agency and we would rather be plain about this.

• We do not hold SOC 2, ISO 27001 or any other security certification.
• We have not commissioned an independent penetration test of this site.
• We do not run a bug bounty.

If your procurement process needs a security questionnaire answered, send it over. We will answer it honestly.

6. Reporting a vulnerability

If you find a security problem with this site or the readiness check, we want to hear about it. Email hello@recommendedbyagents.com with "Security report" in the subject line.

What to include

• The URL or part of the site affected.
• What you found and why it matters.
• Steps to reproduce it. A request or a short proof of concept helps a lot.
• When you found it, and how to reach you.

Please leave out any personal data or secrets you came across. Tell us that they exist, and we will take it from there.

What to expect

• A person will read your report and reply. We aim to acknowledge it within five business days.
• We will tell you what we plan to do, and let you know when it is fixed.
• We are happy to credit you by name if you would like that.
• There is no bug bounty. We cannot pay for reports.

Good-faith research

If you act in good faith and follow the guidelines below, we will treat your research as authorized, and we will not take or support legal action against you for it.

• Only test this website and the readiness check. Vercel, Formspree, Google and Calendly have their own disclosure programs.
• Do not access, change or delete data that is not yours. Stop and tell us as soon as you come across any.
• Do not run denial-of-service tests, send spam through our forms, or use social engineering.
• Do not use the readiness check to attack other sites.
• Give us a reasonable time to fix the problem before you make it public.

7. Changes to this page

When the site or the check changes in a way that affects this page, we will update it and change the date at the top.