How to Check if a Website Is Secure: A 10-Minute Audit

Quick answer: To check if a website is secure, run five free passive checks: confirm HTTP redirects to a valid HTTPS certificate with TLS 1.2+, verify security headers like CSP and HSTS, scan for exposed .env and .git files, check SPF, DKIM, and DMARC records, and look for a public status page. The whole audit takes about ten minutes.

By Daniel A · Kraftwire Software

The whole audit takes about ten minutes.

Key Takeaway

You can verify the essentials of any website's security in about ten minutes using free browser-based checks: a valid HTTPS certificate, security headers, no exposed configuration files, and email spoofing protection. The browser padlock only proves the connection is encrypted · it says nothing about how the site handles your data once it arrives. This proves that even modern, "vibe-coded" sites often have hidden gaps that a quick audit can reveal.

What Does the Padlock Actually Mean?

The padlock, or in newer browsers the absence of a "Not secure" warning, means one thing: traffic between your browser and the site is encrypted with TLS. That stops someone on the same network from reading what you send.

Here is what it does not mean:

• It does not mean the site is legitimate · phishing sites get valid certificates in minutes, for free.
• It does not mean the site stores your data safely.
• It does not mean the code behind the login form is secure.

Since certificates became free and automatic, the padlock stopped being a trust signal and became a baseline. Its absence is disqualifying; its presence proves almost nothing. The checks below are how you actually form an opinion.

What Should You Know Before You Start?

Everything below is passive: you are reading public configuration, the same way a browser or a mail server would. You are not attacking anything, so these checks are appropriate for a vendor's site as well as your own. Total time is about ten minutes, with no accounts and nothing to install. This is the foundation of a web application security audit checklist.

Step 1 · Does the Site Use HTTPS With a Valid Certificate? (2 minutes)

Type the site's address with http:// in front. It should immediately redirect to https://.

Red flags:

• An expired certificate.
• No redirect from HTTP to HTTPS.

Step 2 · Are Security Headers in Place? (2 minutes)

Security headers are instructions a site sends to every browser: what content may load, whether the site can be embedded in a frame, and whether plain HTTP is ever acceptable again. They are the difference between a browser actively defending you and a browser hoping for the best.

Run the domain through the security headers checker. You are looking for:

• Strict-Transport-Security (HSTS): Forces HTTPS.
• Content-Security-Policy (CSP): Prevents XSS by restricting where scripts load from.
• X-Content-Type-Options: Prevents MIME-sniffing.
• X-Frame-Options: Prevents clickjacking.
• Referrer-Policy: Controls how much info is sent when clicking links.

Missing headers are extremely common. A site with a thoughtful CSP almost always has an operator who cared about the rest too.

Step 3 · Are Sensitive Files Exposed? (2 minutes)

This is the check with the highest damage potential. Development leaves artifacts, and misconfigured deployments serve them publicly: .env files full of credentials, .git directories exposing full source history, database dumps, or editor backup files.

The exposed files scanner checks common paths in one pass. If you are auditing your own site and find your .env served publicly, treat every credential in it as stolen: rotate the keys first, then fix the deployment. You can find more on this in our guide on how to remove secrets from git history.

An exposed environment file on a live site is a critical finding, full stop · it converts every other protection on this list into decoration.

Step 4 · Is the Domain Protected From Email Spoofing? (2 minutes)

Can an attacker send email that appears to come from this domain? Three DNS records decide: SPF says which servers may send, DKIM cryptographically signs messages, and DMARC tells receiving servers what to do when the first two fail.

Run the domain through the email security checker. A missing DMARC record, or a policy permanently stuck at p=none, means phishing emails "from" this domain will keep landing in inboxes. For a vendor, that is their users getting phished under their name. For your own domain, this is a fifteen-minute DNS fix with outsized payoff. Learn more about SPF, DKIM, and DMARC in our glossary.

Step 5 · Is the Operator Transparent About Uptime? (2 minutes)

Finally, a soft signal that is more predictive than it looks: does the operator publish a status page and communicate about incidents? Look for a status link in the footer or try the status. subdomain.

Transparency about downtime correlates strongly with operational maturity. Teams that publish incident timelines tend to be the same teams that patch quickly and monitor properly. We cover why this matters, and how to set one up for your own product, in uptime monitoring and status pages.

The Ten-Minute Scorecard

• Security headers · HSTS, CSP, nosniff, and frame protection present.
• Exposed files · nothing sensitive reachable at common paths.
• Email protection · SPF, DKIM, and an enforcing DMARC policy.
• Transparency · public status page with incident history.

Three or fewer passes on a site that wants your payment details or personal data is a real signal · not proof of a breach, but proof that security is not anyone's job there.

What Won't This Audit Catch?

Ten minutes of passive checks cannot see authentication flaws, broken access control, injection vulnerabilities, or whether the database lets any signed-in user read every row. Those require either access to the source or a proper scan of the running application. Treat this audit as a screening test: it reliably detects neglect, but it cannot certify safety.

When you are ready to go deeper on your own site, the full security audit checklist covers the layers this quick pass skips, and our free security tools roundup lists single-purpose checkers for the individual questions that come up along the way.

Security for AI-Built (Vibe-Coded) Apps

If you are building with tools like Lovable, Bolt.new, or Cursor, your security needs are unique. AI often prioritizes "vibes" and functionality over security defaults.

For these apps, you must specifically check:

• Supabase RLS: Ensure Row Level Security is enabled.
• Exposed API Keys: AI often hardcodes keys in frontend code.
• Broken Auth: Verify that users can't access each other's data.

Check out our vibe coding security checklist for a tailored approach to securing AI-generated code.

How Often Should You Repeat These Checks?

Security posture drifts. Certificates expire, a deploy overwrites the headers file, a new subdomain launches without DMARC, or a debugging session leaves a dump file in the web root. Every check on this list can pass in January and fail in March without anyone touching "security" directly.

A reasonable cadence:

• Your own production site: after every significant deploy, and monthly at minimum.
• A vendor you depend on: before you sign, and again before any renewal.
• A site you are about to give payment details to: right now, once · the ten minutes are worth it for anything meaningful.

If repeating manual checks sounds like the kind of thing you will do twice and then forget, that instinct is correct for most people. Automated monitoring exists precisely because humans do not re-run checklists.

How Is Checking Your Own Site Different From a Vendor's?

For a vendor's site, passive checks are as far as you can ethically go. Combine the scorecard with direct questions: where is data stored, is there a security page, how are incidents disclosed? A vendor that fails the ten-minute basics is answering those questions for you.

For your own site, every failed check above is roughly an afternoon of fixes, and passing all five puts you ahead of most of the web. Then go beyond passive checks · you own the site, so you are allowed to scan it properly, including the parts a passerby cannot see. If the site in question is yours, run a free security scan and get the full picture in less time than this audit took.