Names no specific company or product — this compares against clicking through your own provider's console, a manual habit every bucket owner already has, not a company or product this could be mistaken for.
| Checking the console by hand | This tool | |
|---|---|---|
| What it reads | The settings a person configured — bucket policy, ACLs, the account-level public-access toggle | The actual response an anonymous, unauthenticated request receives |
| Catches a policy/ACL/account-toggle conflict | Only if you know which layer wins and check the right one | Yes — it sends the real request, so it reports what wins, not what any one setting says in isolation |
| Repeatable in CI | No — a manual click-through | Yes — a scriptable exit code (0 private/not-found, 1 exposed) |
| Catches drift after a deploy or a policy edit | Only the next time someone happens to look | Every run, on demand or on a schedule |
Your cloud provider's console shows you the settings you (or someone on your team) configured: a bucket policy document, an ACL grant list, an account-level "Block Public Access" toggle. That is a real, useful read of intent -- what the configuration says should happen.
Several independent settings can each grant or block public listing, and the console shows each one separately -- it does not always make obvious which one actually wins for an anonymous, unauthenticated request. A bucket policy statement can grant s3:ListBucket to a wildcard principal while a different admin reads only the account-level Block Public Access toggle and sees it enabled, not realising a resource-level policy can still take effect depending on how it was applied. An old ACL grant from before a stricter policy was added can persist unnoticed. A storage account's container-level "Public access level" in Azure can be set independently of the account's own "Allow Blob public access" setting, and either alone reading "restricted" does not confirm the other agrees. The only way to know for certain what an anonymous outsider receives is to actually send the anonymous request they would send -- which is what this tool does, and reading five separate settings correctly by hand does not replace.
A console check is a point-in-time, manual look. A new bucket policy statement, a fresh IaC deploy, or a teammate widening an ACL for a one-off debugging session can reopen a bucket at any point after the last time someone happened to look. The CLI here returns a real exit code, so it can gate a deploy the same way a linter or test suite does -- catching a regression the day it ships rather than the next time someone thinks to open the console.