Free website security checker
Check how your site protects its visitors: HTTPS and the http→https redirect, the SSL/TLS certificate, the values of your security headers, cookie flags, CORS and mixed content. It's a passive, read-only configuration check that sends only normal GET and HEAD requests — not a penetration test.
What this tool checks
HTTPS and redirects
Whether the page ends up on https:// after redirects, the hops on the way, and whether http://yourdomain/ answers with a permanent (301 or 308) redirect to HTTPS.
SSL/TLS certificate
Whether the certificate is trusted and matches your domain, which TLS version is used, who issued it and how many days until it expires.
HSTS value
The Strict-Transport-Security header is parsed, not just detected: a max-age of at least 180 days, no malformed directives, includeSubDomains, and whether a preload flag is backed by the settings the preload list needs.
Content-Security-Policy directives
Each directive is read: whether scripts are restricted at all, 'unsafe-inline' (not flagged when a nonce or hash is used), 'unsafe-eval', broad sources such as *, https: or data: in script-src, object-src, base-uri, and whether the policy is only Report-Only.
Clickjacking protection
X-Frame-Options (including invalid values and the obsolete ALLOW-FROM), or a CSP frame-ancestors rule that isn't * or a bare scheme.
Other protective headers
X-Content-Type-Options must be exactly nosniff; Referrer-Policy is checked for unsafe-url and unrecognised values; Permissions-Policy for features left open. Cross-origin isolation headers are listed for information.
Version disclosure and source maps
Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version and X-Generator headers that reveal version numbers, and public source maps for up to three of your own scripts.
Cookie flags
Cookies set by the page response, by name only: Secure on HTTPS, HttpOnly on cookies whose names suggest a session or token, SameSite=None without Secure, a missing SameSite, and cookies scoped to a parent domain.
CORS
One extra request with a harmless, made-up Origin (https://rudra-audit.invalid) to see whether your server echoes any origin back — and whether it also allows credentials, which is the risky combination.
Mixed content
http:// scripts, stylesheets or frames on an HTTPS page (active mixed content) and http:// images or media (passive).
security.txt
Whether /.well-known/security.txt exists and has a Contact line and an Expires date in the future, so researchers know how to reach you.
Technologies and visible surface
Frameworks and services recognisable from headers and HTML, plus login forms, API or documentation URLs mentioned in the page and public files such as robots.txt. Listed for awareness; it costs no points.
Client-side patterns (manual review)
Inline event handlers such as onclick, and third-party scripts loaded without Subresource Integrity. These are low-priority hints to review, not confirmed vulnerabilities.
How the check works
We send one normal GET request to your page, follow any redirects and read the response: header values, the cookies it sets (names and flags only) and the HTML. Alongside it we make a small, fixed set of read-only requests: a TLS connection to validate the certificate, one GET with a harmless test Origin for CORS, one request to http://yourdomain/ to see how it redirects, the allowlisted files /.well-known/security.txt, robots.txt, sitemap.xml, humans.txt and the manifest your page links to, and — for up to three of your own scripts — the end of the file plus a HEAD request for the source map it names.
Nothing is submitted, no credentials are sent, no attack payloads are used and no paths are guessed. Requests to private or internal network addresses are blocked. If the page answers with a server error (5xx), we don't analyse its headers, because error pages often differ from the real site; those checks are marked as not run instead of failed.
The score starts at 100 and every deduction is listed in the report. Not using HTTPS costs 40 points, an invalid or expired certificate 40, a failed TLS connection 30, CORS that trusts any origin with credentials 25, a missing HSTS header 15 and a missing CSP 12. Weaker settings cost less — for example no http→https redirect 10, active mixed content 8, a CSP that is only Report-Only 8, 'unsafe-inline' scripts 6, cookies without Secure 6 and a short HSTS max-age 5. Many informational findings, such as a missing security.txt, cost nothing, and the same problem is never deducted twice.
Evidence you'll see
Every header is shown with its actual value and a plain assessment (good, weak or missing); CSP findings include the parsed directive table; cookie findings list cookie names and their flags, never values; the CORS result shows the test origin and what came back. Each finding states what we expected, the URL it applies to, how confident the check is and its source — the HTTP response, the HTML or the TLS connection.
What this tool does not check
It isn't a penetration test
No exploitation, no attack payloads, no brute forcing and no guessing of hidden paths. It reads the configuration any browser receives.
Pages behind a login
We never sign in or send credentials, so authenticated pages, admin areas and account settings aren't tested.
Your code and dependencies
No server-side code review and no vulnerability scanning of your CMS, plugins, libraries or server software.
Malware or a compromised site
It doesn't look for malware, defacement, spam injection or leaked accounts.
Every cookie your site uses
Only cookies set by the page's own response are seen — not ones added later by JavaScript, other pages or third parties. Cookie values are never read.
How your forms behave
Forms are noted but never submitted, so server-side validation, CSRF protection and rate limiting can't be tested.
Common problems we find
HSTS missing or too short
Very common, even on sites that redirect everything to HTTPS — and a max-age of a few minutes, left over from testing, gives almost no protection.
No CSP, or one that allows too much
The most frequently missing header. When it is present, 'unsafe-inline', 'unsafe-eval' or a * in script-src often undo most of its protection.
No clickjacking protection
Neither X-Frame-Options nor a frame-ancestors rule.
Certificates close to expiry
Usually because automatic renewal stopped working after a server or DNS change.
Server version on show
Headers like “Server: Apache/2.4.41” or “X-Powered-By: PHP/7.4” that tell attackers what to look for.
HTTP that doesn't redirect
http://yourdomain/ still serves pages, or redirects only temporarily (302), so visitors who type the bare domain can browse unencrypted.
Session cookies without Secure or HttpOnly
Login or session cookies that scripts can read, or that could be sent over plain HTTP.
How to fix them
Set headers where your site is served
Headers are configured in your web server (Nginx add_header, Apache Header set), your CDN, or your host's settings or headers file. Re-run the check to confirm the value that actually reaches browsers.
Turn on HSTS once HTTPS works everywhere
Use Strict-Transport-Security: max-age=31536000 (180 days is the minimum we accept). Add includeSubDomains only when every subdomain supports HTTPS, and preload last.
Tighten CSP gradually
Start with Content-Security-Policy-Report-Only, then enforce. Replace 'unsafe-inline' with nonces or hashes, drop 'unsafe-eval', list exact script origins instead of * or https:, and add object-src 'none' and base-uri 'self'.
Add the simple headers
X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and X-Frame-Options: DENY (or SAMEORIGIN) rarely break anything.
Automate certificate renewal and redirects
Use managed certificates or Let's Encrypt with automatic renewal, and redirect every http:// request with a 301 or 308 to the same https:// URL.
Hide version numbers
Turn off version tokens (for example server_tokens off in Nginx, expose_php = Off in PHP) and don't publish source maps on production unless you mean to.
Flag your cookies
Give every cookie Secure on an HTTPS site, add HttpOnly to session and login cookies, and set SameSite=Lax (or Strict) explicitly. SameSite=None always needs Secure.
Frequently asked questions
Is this a penetration test or a vulnerability scan?
No. It reads the configuration any browser receives — HTTPS, the certificate, header values, cookie flags, CORS — using only normal GET and HEAD requests. It doesn't try to find or exploit vulnerabilities. For that, hire a qualified security tester and give them permission in writing.
Can it tell me if my site has been hacked?
No. It doesn't scan for malware, defaced pages or compromised accounts. A good score means the visible parts of your transport and browser security are configured well — not that the site is secure in every way.
Does it judge how good my headers are?
Yes, for the main ones. HSTS is checked for a max-age of at least 180 days and malformed directives; CSP is parsed directive by directive for 'unsafe-inline', 'unsafe-eval', broad script sources and missing object-src or base-uri; X-Frame-Options, X-Content-Type-Options and Referrer-Policy values are validated too.
Why isn't HSTS checked on my HTTP site?
HSTS only has an effect over HTTPS. If your site isn't on HTTPS, that is the bigger problem, and it's reported instead.
Can adding security headers break my site?
Most headers are safe to add. A Content-Security-Policy can block scripts, styles or embeds your site relies on, so test it in report-only mode first. Adding Secure or SameSite to cookies can affect logins that span several domains, so test sign-in afterwards.
Is the CORS check safe for my site?
Yes. It is one ordinary GET request carrying an Origin header for a domain that can't exist (rudra-audit.invalid). No cookies or credentials are sent and nothing is changed; we only read which CORS headers come back.
Why are some findings marked as needing manual review?
Patterns such as inline onclick handlers or scripts without Subresource Integrity can be fine or risky depending on context. We flag them with low confidence so you can decide, instead of presenting them as confirmed problems.
Helpful guides
- How to check your website's security: what a passive check can and can't tell youWhat you can safely check about your own site's security in an afternoon, what a passive scanner actually looks at, and where you need a person instead.Read the guide
- What are security headers? What each one does and how to add themSecurity headers switch on protections built into every browser. What each one does, safe starting values, and how to add them on common servers and platforms.Read the guide
- Content-Security-Policy explained: directives, unsafe-inline, nonces and a safe rolloutCSP is the most powerful security header and the easiest to get wrong. The directives that matter, how nonces and hashes replace 'unsafe-inline', and a rollout plan that won't break your site.Read the guide
- How to check cookie security: Secure, HttpOnly, SameSite and cookie prefixesSession cookies are keys to your visitors' accounts. How each cookie attribute protects them, how to inspect your own cookies, and how to set them correctly.Read the guide
Related free tools
- Website AuditCheck one page for SEO, speed, mobile, accessibility, security, broken links and server problems in a single report.Open Website Audit
- API TesterSend a request to any public API endpoint and see the status code, response time and whether it succeeded.Open API Tester
- SEO CheckerCheck your page title, description, headings, image descriptions, canonical URL, robots.txt and sitemap.Open SEO Checker
Rather have someone fix it for you?
These checks are free and so are the guides. If you'd prefer a person to make the changes, our team offers paid help.