Grade B — 3 to fix, 2 minor.
passive scan · the deep checks need you signed in · scanned 27d ago
This is a passive website security report for share.google, graded B (75/100). We checked its SSL certificate, HTTP security headers, DNS records, email spoofing protection and publicly exposed files — the same surface a browser and a search engine already see.
We found 5 issues on this scan — each has a plain-English explanation and a copy-paste fix below.
Not your site? Get the same free report for yours →
Your site is served over HTTPS but doesn't send a Strict-Transport-Security header. Without it, the first visit (or a link typed as http://) can be intercepted and downgraded to plain HTTP before the redirect happens — a foothold for man-in-the-middle attacks on public Wi-Fi.
Nothing stops your site from being embedded in an <iframe> on another domain. An attacker can overlay an invisible frame of your app on their page and trick a logged-in user into clicking buttons they can't see — a clickjacking attack.
You have a Content-Security-Policy, which is great — but it contains a wildcard source or allows 'unsafe-inline'/'unsafe-eval' in script-src. Those let injected scripts execute, which is most of what a CSP is meant to stop.
Visiting http://share.google (no "s") serves the site over an unencrypted connection instead of redirecting to HTTPS. Anyone typing the bare domain, or following an old http:// link, gets an unencrypted page where their traffic can be read or modified in transit.
share.google is not protected by DNSSEC. DNSSEC signs your DNS records so resolvers can detect a forged answer — without it, an attacker who can poison DNS could point your domain at their own server without touching anything you control.
Sign up to fix these — then run the checks a passive scan can't. The stuff that actually gets vibe-coded apps hacked:
free for your first app · no card
Not share.google? Scan your own site free →