How to check your website's security: what a passive check can and can't tell you
What 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.
"Is my website secure?" has no yes-or-no answer, but it does have a useful first step: check the parts of your security that anyone on the internet can already see. Every browser that visits your site receives your HTTPS setup, your certificate, your response headers and your cookies. If those are misconfigured, you're making attacks easier for no reason, and fixing them is usually a settings change rather than a rewrite.
This guide walks through what to check, how to check it, and — just as important — what a check like this can't tell you.
Passive checks versus security testing
A passive check makes the same kind of requests a browser does and reads the answers. It never sends attack payloads, never submits forms and never tries to log in. That makes it safe to run against a live site at any time, and it's good at finding configuration mistakes.
A penetration test is different: a qualified person, with your permission, actively tries to break in — testing logins, input handling, access control and business logic. It finds the vulnerabilities a passive check can't see, and it isn't something to improvise against a production site.
Start with the passive layer. It's quick, and a site that gets the visible basics wrong usually has other problems too.
What to check, and what good looks like
1. HTTPS everywhere, with a permanent redirect
Every page should load over https://, and typing the bare http:// address should answer with a 301 or 308 redirect to the HTTPS version. A 302 works but isn't remembered, and a site that still serves pages over plain HTTP lets anyone on the same network read or alter them. Test it with curl -I http://yourdomain.com/ and look at the status line and the Location header.
2. A valid certificate that renews itself
The certificate must be trusted, match your domain and not be close to expiry. Expired certificates are almost always a renewal job that silently stopped after a server or DNS change. Click the padlock in your browser to see the issuer and expiry date, and make sure renewal is automated.
3. Security headers with sensible values
Headers such as Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and Referrer-Policy switch on protections built into browsers. Their values matter as much as their presence: an HSTS max-age of 300 seconds left over from testing protects almost nothing, and a CSP containing 'unsafe-inline' or * in script-src does little against injected scripts. Our guides to security headers and Content-Security-Policy explain safe values.
4. Cookie flags
Session and login cookies should be Secure (HTTPS only), HttpOnly (hidden from JavaScript) and carry an explicit SameSite value. In the browser, open developer tools and look under Application (Chrome, Edge) or Storage (Firefox) → Cookies. The guide on how to check cookie security goes through each flag.
5. CORS that doesn't trust everyone
Cross-Origin Resource Sharing headers tell browsers which other sites may read your responses. The risky pattern is a server that copies any Origin it receives into Access-Control-Allow-Origin and sends Access-Control-Allow-Credentials: true. That lets any website read responses made with your visitors' cookies. Allow specific origins instead.
6. No mixed content
An HTTPS page that loads scripts, stylesheets or frames over http:// has active mixed content, which modern browsers block, often breaking the page. Plain-HTTP images and media are passive mixed content: less dangerous, but they still weaken the padlock. Search your templates and database for hard-coded http:// URLs.
7. What you're telling attackers
Headers like Server: Apache/2.4.41 or X-Powered-By: PHP/7.4 announce exact versions. Public JavaScript source maps can publish your original front-end code. Neither is a vulnerability by itself, but both save an attacker time. Also consider publishing a /.well-known/security.txt file with a Contact and an Expires date, so people who find a problem know how to reach you.
Run a passive security check
Rudra's free security checker reads your HTTPS setup, certificate, header values, cookie flags, CORS and mixed content using only GET and HEAD requests.
How Rudra's security checker does this
The free website security checker automates the list above. It sends one normal request to your page and reads the headers, the cookies it sets (names and flags only, never values) and the HTML. It then makes a small, fixed set of extra read-only requests: a TLS connection for the certificate, one request to http://yourdomain/ to see how it redirects, one request carrying a made-up test origin (https://rudra-audit.invalid) to see how your CORS headers respond, and a short allowlist of well-known files such as security.txt and robots.txt.
Each finding shows the observed value, what a passing value looks like and how confident the check is. Some patterns — inline onclick handlers, or third-party scripts without Subresource Integrity — can be fine or risky depending on context, so they're flagged at low confidence for you to review rather than presented as confirmed problems. The report also lists the technologies and public surface it could see, such as login forms and API URLs mentioned in the page, so you know what's visible from outside.
What a passive check can't tell you
This is where people over-read a good score. A passive check, ours included, does not:
- find vulnerabilities in your code, such as SQL injection, cross-site scripting or broken access control;
- scan your CMS, plugins, libraries or server for known vulnerable versions (unless a header happens to reveal a version);
- test anything behind a login, including admin panels and account pages;
- test how forms behave when submitted, including CSRF protection and rate limiting;
- detect malware, defacement or a compromised account;
- review your hosting, backups, access controls or who has admin passwords.
A clean result means the visible configuration is in good shape. It doesn't mean the site is secure in every way, and no automated scan can promise that.
What to do beyond the scan
- Keep software updated. Apply CMS, plugin, theme and framework updates promptly, and remove plugins you don't use.
- Protect admin accounts. Use unique passwords and two-factor authentication for every account that can change the site.
- Keep tested backups. A backup you've never restored is a hope, not a plan.
- Watch for changes. Re-run the passive check after deployments and whenever you add a third-party script.
- Get a professional test when the stakes justify it. If you handle payments, health data or accounts, commission a penetration test from a qualified tester with a written scope.
For the rest of your site's health — speed, SEO, accessibility and broken links — run a full website audit on the same page.
Frequently asked questions
Is it legal to scan a website for security issues?
Passive checks read what a site sends to every visitor, but you should still only test sites you own or have permission to test. Active testing, such as trying payloads or logins, needs explicit written permission from the owner.
Can a free security checker tell me if my site has been hacked?
No. Configuration checks don't look for malware, injected spam or compromised accounts. If you suspect a compromise, check your host's security tools and logs, and get professional help.
What's the most important thing to fix first?
HTTPS on every page with a permanent redirect from HTTP, and a certificate that renews automatically. After that, session cookie flags, HSTS and a Content-Security-Policy rolled out in report-only mode first.
Does a high security score mean my site is secure?
It means the visible configuration is good: HTTPS, certificate, headers, cookie flags and CORS. It says nothing about vulnerabilities in your code or plugins, which need updates, code review and, for higher-risk sites, a penetration test.