Transport and certificate
Plain http traffic is sent on to https
Visitors who type the address without https land on the encrypted version instead of the plain one.
Learn
Every finding, explained
The free check can report 67 findings. Each one has a page: what it means in plain words, why apps built by a prompt get it, what it affects, and the exact fix. Nothing here is a score and nothing here is a verdict.
67 findingsLast updated September 13, 2026
- Transport and certificate
Plain http traffic is not sent on to https
Someone who reaches the plain http address stays on an unencrypted connection, so anything typed on that page travels in the clear.
- Transport and certificate
The https address did not answer cleanly
Browsers show a warning page or refuse the connection, so most visitors never reach the app at all.
- Transport and certificate
The page loads some files over plain http
Browsers block or downgrade these files, so parts of the page can break, and the padlock treatment is lost.
- Transport and certificate
Every file on the page loads over https
Nothing on the page is pulled over a plain connection.
- Response headers
Strict-Transport-Security is set
Browsers remember to use https for this domain on later visits.
- Response headers
Strict-Transport-Security is not set
A browser that has been to the site before can still be pushed to the plain http version on a hostile network.
- Response headers
Content-Security-Policy is set
The page tells the browser which sources of scripts and styles it will accept.
- Response headers
Content-Security-Policy is not set
If any injected markup reaches a page, the browser has no rule telling it which scripts it is allowed to run.
- Response headers
The content policy allows inline scripts
The script-src rule includes unsafe-inline, which removes most of the protection the policy would otherwise give.
- Response headers
X-Content-Type-Options is set
Browsers will not guess a file type that differs from the one you declared.
- Response headers
X-Content-Type-Options is not set
A browser may treat an uploaded or user supplied file as a script because it guesses the type.
- Response headers
Framing is restricted
Other sites cannot silently place your pages inside their own.
- Response headers
Framing is not restricted
Another site can load your pages inside an invisible frame and trick a signed in visitor into clicking things they cannot see.
- Response headers
Referrer-Policy is set
Outbound links do not carry the full address of the page the visitor came from.
- Response headers
Referrer-Policy is not set
Full page addresses, including anything you put in a path or query string, are sent to third party sites your pages link to or load from.
- Response headers
Permissions-Policy is set
Camera, microphone, and location access are limited to what you named.
- Response headers
Permissions-Policy is not set
Embedded third party frames can ask for camera, microphone, or location on your domain's behalf.
- Source maps
Source maps are published next to the app code
Anyone can rebuild your original files, including comments, file names, and any logic you assumed was hidden.
- Source maps
No published source maps were reachable
The bundles checked did not resolve to a readable source map.
- Secrets in the bundle
A server side key appears in code the browser downloads
Anyone who opens the page can read this key and use it directly against the service it belongs to, with your account paying for it.
- Secrets in the bundle
No server side keys matched in the downloaded code
The known server key patterns did not appear in the files checked. Publishable and browser keys are expected there and are ignored.
- Fingerprint
What the outside of the app reveals
Anyone can see this from a browser. It is listed so you know what is on show.
- Fingerprint
A response header names a software version
Naming the exact version tells anyone scanning the internet which known issues to try first against your host.
- Exposed paths
A file that should not be public answers on the live site
This file usually carries configuration, keys, or repository history, and it is readable by anyone who asks for it.
- Exposed paths
The common private files did not answer
Requests for configuration and repository files came back empty or missing.
- Exposed paths
Public information files
These files tell crawlers and researchers how to treat the site.
- Trust evidence
The hosting platform publishes its own check results
The platform reports the following checks for this app: {checks}.
- Database exposure
Some database tables answer without anyone signing in
A request made with the browser key alone returned rows, which means the row rules on those tables let anonymous readers in.
- Database exposure
The table list is not readable without signing in
An anonymous request could not list the tables behind the app.
- Database exposure
Functions callable by name from the public schema
The public schema names {total} functions callable by name: {functions}. Whether each checks authorization needs a code review. ShipReady lists the names and never calls them, which is why backend rules stay on the not verified list.
- Cookies
A cookie is missing a protective flag
A cookie without Secure can travel over a plain connection, and one without HttpOnly can be read by any script on the page.
- Cookies
Cookies on the first response look fine
No cookie was set without its protective flags on this response.
- Cookies
No cookies were set on the first response
The landing response set no cookies, so there were no flags to check.
- Email authentication
An SPF record is published
Mail servers can see which services are allowed to send using your domain.
- Email authentication
No SPF record is published
Anyone can send mail that claims to come from your domain, and your own mail is more likely to land in spam.
- Email authentication
A DMARC record is published
You have told receiving servers what to do with mail that fails the checks.
- Email authentication
No DMARC record is published
Receiving servers have no instruction for mail that fails the checks, so forged mail from your domain is more likely to be delivered.
- Email authentication
Mail records were not checked for this address
The app is on a shared hosting domain ({domain}), so its mail records belong to the platform and not to you.
- Policy pages
A privacy page is linked
Visitors can find how their information is handled.
- Policy pages
No privacy page is linked
Payment providers, app stores, and several privacy laws expect a reachable privacy page before you take anyone's details.
- Policy pages
A terms page is linked
Visitors can find the rules of using the product.
- Policy pages
No terms page is linked
Without stated terms you have no written basis for suspending misuse or limiting your liability.
- Policy pages
A refund or returns page is linked
Buyers can see the refund position before they pay.
- Policy pages
No refund or returns page is linked
Card processors expect a stated refund position, and disputes are harder to answer without one.
- File storage
The storage bucket list answers without a sign in
A request with the browser key returned the names of {total} storage buckets: {buckets}. Names alone give a reader the shape of what you store.
- File storage
Some storage buckets are readable by anyone with the address
These buckets are marked public, so any file inside one can be read by anyone who knows or guesses its address: {buckets}.
- File storage
Storage buckets list their objects without a sign in
An object list request carrying only the browser key came back from these buckets: {buckets}. The counts show how much is behind each name. ShipReady records names and counts and never keeps an object name or a file.
- File storage
Files in a listing bucket open without a session
One object address from each of these buckets answered a plain request with no session: {buckets}. Anything stored there can be read by anyone who can list it.
- File storage
Storage did not answer an anonymous request
The bucket listing did not come back to a request holding only the browser key.
- Cross origin rules
Any site can read your responses with a visitor's session
{path} answered a request from an outside origin with an allow origin of {origin} and credentials allowed, so a page on another domain can read responses using your visitor's session.
- Cross origin rules
Cross origin reads are open to every site
{path} answered with an allow origin of {origin}, so any site can read what it returns. Without credentials that is only a problem for data you did not mean to publish.
- Cross origin rules
Cross origin rules are narrow or absent
A request from an outside origin came back without a header inviting other sites to read the response.
- Domain registration
The domain registration comes up for renewal
The public registry record says {domain} expires on {expiry}, which is {days} days away. That is close enough to put a renewal on the calendar now.
- Domain registration
The domain registration expires soon
The public registry record says {domain} expires on {expiry}, which is {days} days away. An expired domain takes the app, the mail, and the sign in links with it.
- Domain registration
The domain registration has time left
The public registry record says {domain} expires on {expiry}, {days} days away.
- Domain registration
The app runs on a shared platform domain
{domain} belongs to the hosting platform, so there is no registration of yours to expire and no registry record to read.
- Firebase exposure
The Firebase database answers without a sign in
A plain request to {endpoint} returned data with no sign in, so the rules on that database let anonymous readers in.
- Firebase exposure
Firebase storage listed its contents without a sign in
A plain request to {endpoint} returned an object listing with no sign in, so anyone can enumerate what is stored.
- Firebase exposure
Firestore collections answer without a sign in
Requests with no sign in came back with documents from these collections: {collections}. ShipReady records the collection names and the counts and never keeps a document.
- Firebase exposure
Firebase endpoints did not answer an anonymous request
The database and storage endpoints refused a request that carried no sign in.
- Sign in settings
Anyone can create an account
The public auth settings at {endpoint} report that self signup is on, so a script can create accounts at will.
- Sign in settings
New accounts are confirmed automatically
The public auth settings report that new sign ups are confirmed automatically, so an account can be created with an address the person does not own. You did not declare customer data, so this is recorded rather than raised.
- Sign in settings
Anonymous sign in is turned on
The public auth settings at {endpoint} report anonymous sign in is on, so a caller can hold a session without ever giving an address. That is fine when it is deliberate and a problem when row rules assume a known person.
- Sign in settings
New accounts are active before the address is confirmed
The public auth settings report that new sign ups are confirmed automatically, so an account can be created with an address the person does not own.
- Sign in settings
Sign in methods published by the backend
The public auth settings list these sign in methods: {providers}.
- Sign in settings
The auth settings read as expected
Self signup is closed and new accounts have to confirm their address.
Check your app
Run all sixteen groups on your published address and see the evidence behind every result.
ShipReady is not a penetration test or a security certification. No automated check can prove an application is secure.
Last updated September 20, 2026