Website security audit terms, in plain English.
Who may run a scan, what the tool does and does not do, what a report is worth, and what we keep afterwards. Short sentences, because you should be able to read all of it.
last updated 10 September 2026 · applies to the audit at /tools/website-security-audit
1. Who can use this
You can scan a site you own, or a site whose owner has given you permission to test it. That is the whole rule. If neither is true, close the page.
Getting that permission is your job, not ours. Ownership of the domain is not always enough. If the site runs on shared hosting, a managed platform or someone else’s infrastructure, your host’s terms may also apply, and some hosts treat any third-party testing as a breach of contract. Check before you scan. If you are a consultant scanning for a client, get it in writing from the client, and get it in writing before the first scan rather than after a complaint.
We may ask you to show us that permission. If we do and you cannot, or if we think a scan was run without it, we will stop the scan, delete the report and block further use from you. We can do that at any time, for any domain, without notice. It is a free tool and there is nothing to refund.
2. What you must not do
- Scan a site you are not allowed to scan
- Use a report to plan an attack, or as reconnaissance for one
- Route around a rate limit with proxies, VPNs or repeat attempts
- Resell the tool, or run it from a script or a scheduler
- Build our results into another product without asking us first
The reconnaissance point is the one we care most about. A report describes what a server tells the public, and that is useful to an owner fixing it and to an attacker choosing a target. Using it as the second is a misuse of the tool and, depending on where you are, a criminal offence.
The rate limits are there so the tool stays available and so we stay a light guest on other people’s servers. Working around them with a pool of addresses is not a clever workaround, it is the thing the limit exists to prevent. If you have a legitimate reason to run more scans than the limit allows, mail security@eazetech.co and ask. We would rather agree something than watch you rotate proxies.
3. What the tool actually does
The audit sends ordinary unauthenticated HTTP requests, performs a TLS handshake with the host, and looks up public DNS records for the name you submitted. That is the entire mechanism. The report is assembled from the response headers, the certificate, the redirect chain and three well-known files that servers publish on purpose.
It does not try to get past a login, a paywall, an IP allowlist or any other access control. It does not guess at paths or look for files you have not linked. It sends no malicious or malformed traffic: no injection payloads, no traversal strings, no oversized headers, nothing a browser could not have sent. It does not test for exploits, so it will never tell you that a vulnerability is confirmed, only that a configuration looks like one that tends to cause problems.
The full request list, the concurrency and redirect limits, and the exact user agent are on the scanner page. That page is written for the person reading the server logs on the other side, and it is the one to send to a host who asks what hit them.
4. No guarantees
The audit is provided as is. It may be unavailable, it may be slow, and it may be wrong. It can report a problem that is not there, and it can miss one that is. A header can be set at a layer we cannot see. A CDN can answer us differently from the way it answers your users. A certificate can be replaced a minute after we looked.
It also cannot find most kinds of problem, by design. It never authenticates, so it sees nothing behind a login. It never guesses at paths, so it will not find the forgotten backup file. It does not read your code, your database, your cloud configuration or your dependency tree. It looks at what one server publishes to one anonymous visitor at one moment.
So, plainly: a clean report does not mean a site is secure. It means the handful of public signals we checked looked reasonable when we checked them. Treat it as one input, not as a verdict, and do not let it replace a real penetration test by people who are allowed to try.
To the extent the law allows it, we are not liable for what happens because you relied on a report, acted on one, or did not.
5. If someone sues us over your scan
If a third party brings a claim against us because of how you used the audit, you cover our costs. That means legal fees, damages and anything we pay to settle. The obvious case is a scan run without permission, where the site owner or their host comes after the company whose name was in the user agent.
We will tell you promptly if a claim like that arrives, and we will not settle one in your name without talking to you first.
6. Not legal or compliance advice
A report is a set of technical observations about one address at one point in time. It certifies nothing. It is not an audit under PCI DSS, SOC 2, ISO 27001, HIPAA or the GDPR, and it does not show that you meet any of them. It is not legal advice about your obligations.
Please do not hand a report to a customer, an insurer or a procurement team as evidence that a site has been certified, because it has not been, and anyone who knows the standards will say so. If you need a certified assessment, engage an assessor who can issue one.
7. Privacy notice for scanning
This part covers the scanning itself: the data we read from a site being audited and the data we take from the person who asked for the audit. Eazetech Ltd is the controller for both. Questions and requests go to security@eazetech.co.
What we read from a scanned site
The URL that was submitted, the response headers and status codes it returns, the redirect chain, the TLS certificate and the negotiated protocol, the contents of robots.txt, security.txt and sitemap.xml, and public DNS records for the hostname. All of it is published by the site to anyone who asks.
Some of that can still be personal data. A server IP address can identify a person running a small site from home. A security.txt file usually names a contact, and DNS records often carry an email address or a person’s name. We do not go looking for those, but we do read files that contain them, so we say plainly that we handle them.
Why we are allowed to do this
Our lawful basis is legitimate interests, Article 6(1)(f) of the GDPR. Recital 49 names processing that is strictly necessary and proportionate for network and information security as exactly such an interest. Our interest is running a tool that tells site owners what their servers expose, before somebody less friendly works it out.
We think that interest holds because of how narrow the processing is. We read only what is already public, we send fewer than ten requests, we never authenticate, we keep reports for 30 days, and any domain can opt out in one DNS record. If you think the balance falls the other way for your domain, tell us and we will stop scanning it.
Why you did not hear from us first
We get this data from the site, not from the person it might describe, so Article 14 applies rather than Article 13. Article 14(5)(b) lifts the duty to notify each person individually where that would take disproportionate effort. Writing to every contact address we come across in a DNS or security.txt record would mean sending unsolicited mail to abuse inboxes at scale, which is a worse outcome for everyone than publishing this.
So this notice and the scanner page are the public information instead, and the user agent on every request links straight to them.
What we never keep
We do not store the contents of any file we flag. If a report says a path returned something it should not, it records the path, the status and the headers, not the body. We do not store cookies, credentials or authorisation headers of any kind. We strip the query string from a submitted URL before anything is written down, because tokens and session identifiers live there more often than people expect.
Your rights
You can object to this processing, ask us to delete any reports we hold about your domain, or opt the domain out entirely with the DNS record documented on the scanner page. You can also ask for a copy of what we hold, or ask us to correct it.
We verify domain control before acting on any of it, either through a TXT record we give you or a reply from an address at the domain. That check is not bureaucracy: it stops one person suppressing findings about somebody else’s site, which would turn a privacy right into a way of hiding a site from the people responsible for it. Verification usually takes a day. If you are unhappy with how we handle a request, you can complain to your national data protection authority.
how long we keep things
- Scan reports
- 30 days, then deleted
- Submitter IP address
- Hashed with a salt that rotates daily. The raw address is gone within 24 hours
- Aggregate statistics
- Truncated addresses only: IPv4 to /24, IPv6 to /48. Kept 90 days
- Server logs
- 3 months
- Response bodies
- Never written to disk
The daily salt on the submitter hash is rotated and discarded, so yesterday’s hashes cannot be matched to today’s addresses.
Questions, objections and takedowns
Everything about the audit goes to security@eazetech.co: a scan you did not authorise, a report you want deleted, an opt-out you would rather we handled by hand, or a question about anything above. A person reads it and replies. Formal notices go to Eazetech Ltd at hello@dearhearth.com or +1 548 391 4050.
If we change these terms we will change the date at the top of the page. We are not going to pretend that a silent edit counts as notice.