NZAI Security
A New Zealand small business owner at a tidy desk reviewing a free website security scan results on a laptop, with an Auckland suburban street view at golden hour through the window
Cyber Basics

Is Your School or Business Website Secure? Free 10-Second Check

Guide Educators + General Updated 20 Jul 2026

Free 5-check website security scan for NZ schools and small businesses. TLS, headers, exposed files, cookies, mixed content. 10 seconds, no signup.

Written and reviewed by Feroze Ashraff Last reviewed Editorial standards

Quick answer

A free website security check should look at five things: whether your site's TLS certificate is valid and recent, whether it sends modern security headers, whether it accidentally exposes files like .env or .git, whether its cookies are flagged correctly, and whether it serves any content over plain HTTP. Run a free scan at nzscan.nzaisecurity.com — it checks all five in about 10 seconds, no signup required, and gives you a grade with copy-paste fixes for anything that fails.

Most schools and small businesses do not need a paid vulnerability scan to find the problems that matter most. The five checks above catch the cheap, embarrassing misconfigurations that show up on real production sites every day.

Why this matters in New Zealand

New Zealand schools and small businesses are not usually targeted by sophisticated attackers. They are targeted by opportunistic scanning — automated bots that crawl the public web looking for sites with missing security headers, exposed .git directories, or expired TLS certificates. These bots do not care how big your school is. They care that you forgot to set a header in 2019.

The Own Your Online business guidance tells New Zealand businesses to protect business basics before anything else [1]. For a public-facing website, "business basics" means: HTTPS works, modern headers are set, no obvious files are leaking, cookies are flagged correctly. That is what a free smoke test verifies.

If you are an educator, the same checks apply to your school's public website — the one parents and prospective families see. A missing Strict-Transport-Security header is not just a tech mistake; it is a signal to anyone scanning that the site may not be looked after carefully.

Run the free check

This is the part that takes 10 seconds:

  1. Go to nzscan.nzaisecurity.com
  2. Paste your school or business URL
  3. Click Scan

You get a grade (A through F) and a per-check breakdown. Each failed check includes:

  • What is missing
  • Why it matters
  • A copy-paste fix (nginx, Apache, Express, or Cloudflare — whichever you use)
  • A link to a deeper NZAI guide if you want the full explanation

If you are not technical, share the report with whoever manages your website. The fixes are usually 5-10 minutes of configuration, not a rebuild.

What the five checks actually look for

TLS / SSL

  • Is the certificate valid, or has it expired?
  • Is the site forcing TLS 1.2 or 1.3 (modern), or accepting TLS 1.0 / 1.1 (obsolete)?
  • Are weak ciphers being negotiated?
  • Why it matters: Expired certs make browsers refuse to load your site. Weak TLS versions have known attacks against them.

HTTP Headers

  • Content-Security-Policy: present?
  • Strict-Transport-Security (HSTS): present?
  • X-Frame-Options: present?
  • X-Content-Type-Options: present?
  • Referrer-Policy: present?
  • Permissions-Policy: present?
  • Why it matters: These headers tell the browser how to behave when loading your site. Missing headers leave you open to clickjacking, MIME sniffing, and downgrade attacks.

Exposed Files

  • /.env — does it return 200?
  • /.git/config — does it return 200?
  • /backup.zip, /phpinfo.php, /server-status — do any of these return 200?
  • Why it matters: A 200 response means the file is publicly downloadable. For .env and .git, that is a direct breach — environment variables, database passwords, and source code in the open.

Cookies

  • Are cookies set with the Secure flag (HTTPS only)?
  • Are cookies set with the HttpOnly flag (not readable by JavaScript)?
  • Are cookies set with SameSite (CSRF protection)?
  • Why it matters: Cookies without these flags are easier to steal or replay. For a school portal that handles student logins, this is a real exposure.

Redirects and Mixed Content

  • Does the site redirect HTTP to HTTPS?
  • Are there any http:// references inside an HTTPS page?
  • Why it matters: Mixed content is silently blocked by browsers, breaking pages. Long redirect chains slow loading and can mask malicious intermediates.

Common things NZ sites fail on

From running scans across NZ education and small-business sites, the most common findings are:

  • HSTS missing. Most common. Easy fix. Set the header on your web server.
  • /.well-known/security.txt missing. Recommended file — tells researchers how to report vulnerabilities. Five-minute add.
  • Permissions-Policy missing. Newer header. Not critical but google's lighthouse and other scanners flag it.
  • Server banner leaks version info. "nginx/1.18.0" in the response header tells attackers exactly what to look for. Hide it with server_tokens off; (nginx) or ServerTokens Prod (Apache).
  • Long redirect chains. Often www → apex → https → trailing-slash normalisation. Combine into a single redirect.

The good news: every one of these has a known fix. The bad news: most websites never get scanned, so the problems sit there for years.

Free 10-second website security check for NZ schools — TLS, headers, exposed files, cookies, mixed content

What this check does NOT do

Honest scope, so you know what you are getting:

  • It is not a penetration test or vulnerability scan. It looks at the same things your browser sees, not application-layer bugs.
  • It does not see behind logins. Public-facing pages only.
  • It does not detect SQL injection, XSS in your code, or authentication flaws. Those need a real pen test.
  • It runs from a single IP. Sites with aggressive WAFs may rate-limit or block the scan.

If your scan comes back clean, that does not mean your site is unhackable. It means the cheap, embarrassing misconfigurations are not present. That is a good baseline, not a complete answer.

When to use this versus a paid tool

Use the free check if you are:

  • An NZ school checking whether the public website is reasonable
  • A small business that wants to know if your site is doing the basics
  • An educator or IT person doing a quick sanity check on a site you look after

Use a paid vulnerability scanner (UpGuard, Pentest-Tools, etc.) if you are:

  • Subject to compliance requirements (PCI-DSS, ISO 27001, etc.)
  • Running an e-commerce site that processes card data
  • Concerned about application-layer bugs that the free check cannot see

For everyone else, the free five-check smoke test is the right starting point. Run it, fix what fails, re-scan, move on.

Common mistakes when reading the results

A few things people get wrong when they first run a security scan:

  • "I got an A, I'm safe." No. An A means the five checks passed. It does not mean your application code is secure, your password storage is correct, or your users are not being phished.
  • "I got an F, my site is broken." No. An F usually means a few headers are missing — easy fixes, not a redesign. A truly broken site would not load at all.
  • "I need to fix everything today." No. Fix the fails first, then the warnings, then revisit in three months. Security is iterative, not a one-off project.
  • "The tool found X, so X is exploitable." The tool found X is missing. Whether that is exploitable in your specific case depends on your code, your users, and your threat model. Treat findings as "things to investigate," not "confirmed breaches."

What to do next

  1. Run the scan. nzscan.nzaisecurity.com — paste your URL, get a grade in 10 seconds.
  2. Fix the fails. Each failed check has copy-paste fixes for nginx, Apache, Express, and Cloudflare. Hand the report to your web person if you are not technical.
  3. Re-scan. After applying fixes, re-run the scan to confirm the grade improved.
  4. Set a reminder. Re-scan quarterly. New headers get added to the standard, certificates expire, and small config changes can break things that were working.

For deeper NZ-specific guidance on specific failures, the NZAI resource library has separate guides for each:

Knowledge check

Q1Your school website scan came back with grade B, missing the HSTS header. What does HSTS actually do, and is the fix urgent?tap to flip
Answer: HSTS (HTTP Strict Transport Security) tells browsers to only ever load your site over HTTPS, even if the user types http:// or follows an http link. Without it, a one-time downgrade attack can downgrade a visitor to plain HTTP and sniff their traffic. The fix is one line of server config (e.g. nginx add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;) — urgent-ish, but not an emergency unless you know of active downgrade attacks on your users.
Q2Your scan shows /.env returns HTTP 200. Is this a real problem if the file is empty?tap to flip
Answer: Yes — a 200 response means the file is publicly downloadable. Whether it is empty today is irrelevant; the next deploy may put real secrets in it (database passwords, API keys, cloud credentials). Block it at the server level (e.g. nginx location ~ /.(env|git) { deny all; return 404; }) and verify it now returns 404.
Q3Your scan shows no mixed-content issues and an A grade. Does that mean your site is unhackable?tap to flip
Answer: No. A clean scan means the five basic checks pass — TLS, headers, exposed files, cookies, mixed content. It does not check application-layer bugs (SQL injection, XSS in your code, broken authentication, insecure direct object references). For those, you need a real penetration test. Treat the free scan as a baseline, not a complete answer.

Sources and references

[1] Own Your Online. (2026). Get protected: Business. https://www.ownyouronline.govt.nz/business/get-protected/

[2] CERT NZ. (2025). Top 11 cyber security tips. https://www.cert.govt.nz/individuals/guides/top-11-cyber-security-tips/

[3] Mozilla. (2025). Web security guidelines. https://infosec.mozilla.org/guidelines/web_security