Last updated 7 September 2026
Straight answers about what the scan does to your site, what it can and cannot find, and what you get for the price. If yours is not here, email support@scan44.com and we will answer it, and probably add it.
It looks for security problems that are visible from outside your site, working through a library of 133 checks and running the ones that apply to you. That covers keys and secrets left in your published front-end code, databases that answer the public key in your page, admin pages reachable without signing in, source maps publishing your original code, forgotten subdomains and staging sites, files left downloadable in 45 places they get left behind, your certificate and connection settings, browser protection headers, cookie settings, and the email records that stop somebody sending mail as you. A site only gets the checks that make sense for it, so a WordPress check never runs on a Lovable app.
Yes. Every check is read-only: we make the same kind of requests any visitor’s browser makes, read what comes back, and look up public DNS records. We never try passwords, never submit a form, never inject anything, and never change, damage or delete anything. It is usually under a hundred requests spread over about ten seconds, deliberately spread out rather than sent at once, because a check that knocks a small server over is worse than no check at all.
No, on both counts. There is nothing for us to log in to and nothing we write. The one place we do more than read a page is a database check: if your page hands every visitor a public key, we use that same key to ask the database whether a single row would come back, because that is the only way to tell a database with its access rules switched on from one without. The row itself is never fetched, so nothing from your tables is stored or shown in your report, and we never insert, edit or delete.
No. Every problem is explained in plain English first, with what it means for you, the evidence so you can check it yourself, and the steps to fix it. Because most people reading this built their app by describing it to a tool, each finding also comes as a prompt you can copy and paste straight into Claude, Lovable, Bolt, Cursor, v0 or whatever you built with, already carrying the problem and the evidence.
Yes, and those are the sites it was rebuilt for. You can give it your own domain or the address the platform gave you, such as yourapp.lovable.app, and it checks whatever is actually live at that address. The problems it leads with are the ones these tools produce: a key pasted into the page, a database left readable by default, a login screen that looks right while the database still answers anyone who asks it directly, and a staging copy from three weeks ago still online and still connected to your data.
It usually means the key is fine and the rules around it are not. Your page has to carry a public key for the browser to talk to your database at all, so finding one there is normal and is not the finding. What we check is what that key can do: we ask your database whether one row would come back, using nothing but the key your own page already hands to every visitor. If one comes back, that table can be read by anyone holding the key in your page, either because the row level security rule is off or because it says everyone may read. We tell you which tables answered. Which of those is deliberate, a public leaderboard or a menu, is your call to make, and the report says so rather than deciding for you.
Yes. The anon key, and the newer publishable key that replaces it, are designed to sit in your page where the browser can see them, and we do not report either as a leak on its own. What must never be in your page is the service role key, which bypasses every access rule and is a critical finding if we find it there. The anon key is only as safe as the row level security rules behind it, which is why we test those rather than the key.
Rotate it first, then work out how it got into the page. Anything reachable from the browser has already been downloaded by every visitor and by anything that crawled your site, so treating the key as compromised is the only safe assumption, and rotating it costs minutes. Once the new key is issued, it belongs on the server side rather than pasted into front-end code. The report names where in your code the key was found, shows it masked rather than in full, and gives you the steps for that specific kind of key.
No. How many problems your site has and how serious each one is, is free and always will be, and you see it before any payment is mentioned. What costs $19 is the rest of the report: what each problem actually is, the evidence, and the step-by-step fix. Where you have at least one minor problem, one finding is opened in full for free as well, so you can judge the writing and the fix instructions before deciding.
In four situations the whole report is free and no payment is offered. If we found fewer than three issues there is not enough there to be worth money. If nothing we found rises above minor, your site is well run and we are not going to charge you to be told so. If a bot-protection wall answered instead of your website, a whole class of checks could not run. And if your site answered too slowly for some checks to finish, what we found is real but it is not the whole picture.
The report opens on the same page you were already looking at, usually within a few seconds of the payment clearing. There is nothing to install and no email to wait for: the page checks for itself whether the payment has landed and reloads with everything unlocked. From there you can read every finding, copy the fix prompts, and save the report as a PDF to send to somebody else.
There is no account and we never ask for your email address. That is why the link to your report matters: it is the only way back into it, so save it. Your own browser also keeps a short list of the reports you have run on that device, which appears under the box on the front page and never leaves your computer. Our payment provider collects an email address to send you a receipt, and that stays with them.
A report you paid for is kept for ninety days from the payment, then permanently deleted. A scan nobody paid for is kept for two days, which is long enough to read it and decide, and for two weeks if you opened the payment page, so that a payment finished days later still has a report to unlock. We do not keep a database of scanned sites, we never publish results, and there is no page anywhere on this site where one report can be found from another.
Yes, and it is free for thirty days after you buy the report. Every fix tells you what should change once it has worked, so re-checking is how you confirm it rather than hoping. The re-check runs against the same site your report covers and updates that same report, so you are never asked to pay a second time to find out whether the first fix landed.
No, because the report opens the moment you pay and there is nothing to give back. That said, a broken product is our problem: if a finding is factually wrong we will correct the check and re-run your scan at no charge, if your report will not load at any point in the ninety days we will restore it or run the scan again, and a duplicate charge for the same report is returned. Where the law where you live gives you rights this policy cannot remove, those rights stand.
Anything that is only visible from inside your application. Our checks are passive and made from outside, so a flaw in logic that runs after a user signs in, a problem behind a login we do not have, or a mistake in code that never reaches the browser will not appear. Your compiled front-end code is the exception, because your visitors download it too. A clean report means our specific checks did not find the specific problems they look for, and it is not a certificate saying your site is secure.
No. By entering an address you are confirming that you own that site or have the owner’s permission to have it checked, and that responsibility is yours rather than ours. We cannot verify ownership before making the first request and we would rather say so than pretend otherwise, so what we do instead is limit the damage: every check is passive, and the results go only to whoever started it.
Block the user agent SiteCheckBot/1.0 at your firewall or CDN, or email us the domain and we will add it to a list the scanner refuses to check. Both work, and a domain on that list stays on it: the refusal lives in the scanner itself rather than in somebody remembering. Adding a line to robots.txt will not do it, and we would rather tell you that than let you believe it had. Our scanner is not a search crawler, so blocking it costs you nothing anywhere else.
The check is free and takes about ten seconds. Run it from the front page with nothing to sign up for and nothing to install.