nextlevels logo
DEEN
Check your site free

Check website security: The free Security Check

What every attacker sees from the outside: certificate, headers, cookies, exposed files and whether strangers can send email in your name.

  • Read-only, no attacks
  • No signup
  • Instant result

Public websites only. How the port check works and who gets its result is explained in the FAQ.

  • BSI TR-02102
  • BSI TR-03108
  • RFC 7208
  • RFC 6376
  • MDN
  • Art. 32 GDPR

Featured on

  • Featured on Twelve Tools
  • Featured on LaunchIgniter
  • Listed on Turbo0
  • Security Check by nextlevels badge

Related services for website security

What the Security Check covers

A defensive configuration check against the address you submit. No exploits, no attack on credentials – only what your server hands to everyone.

  • HTTPS & TLS

    Do your visitors see a browser warning?

    We check HTTPS availability, HTTP→HTTPS redirects and whether the certificate is valid, matches the hostname and isn't about to expire, against your public host:443 – read-only. Plus the CAA record in DNS.

  • Security headers

    Is your site protected against injected code and clickjacking?

    HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy as delivered by the homepage, including common weaknesses such as unsafe-inline in the CSP, a short HSTS lifetime or CORS that trusts foreign domains with credentials.

  • Cookie flags

    Can session cookies be stolen?

    Visible Set-Cookie headers: Secure, HttpOnly, SameSite – and whether a page that sets cookies may still be stored in shared caches. Report only – no cookie theft or replay.

  • Info leaks

    Are source code or credentials exposed online?

    Server/X-Powered-By banners, directory listings, publicly reachable .git, .env or .DS_Store files, open Apache status pages or phpinfo(), an active debug mode, secret keys in the homepage source and enabled HTTP TRACE, plus robots.txt and security.txt as informational. We never read the contents of sensitive files.

  • Content & scripts

    Does your site load insecure or tamperable files?

    Files embedded over HTTP on the HTTPS homepage (mixed content) and external scripts without Subresource Integrity. We spot both in the delivered HTML without fetching the files. If the HTML reveals the version of jQuery, Bootstrap, AngularJS, Vue, React or WordPress, we check it against known vulnerabilities and end of life.

  • Email senders

    Can someone send phishing emails in your name?

    SPF and DMARC from public DNS: is it defined who may send mail for your domain, and does DMARC enforce quarantine or reject? We look for DKIM under three common selectors.

Get security gaps fixed

What your report looks like

An example, shortened and with a made-up domain. Every finding says what it means for your business and how to fix it.

  • Grade from A to F and score at a glance
  • Every finding rated: fail, warning or note
  • A concrete recommendation for every finding
Check now
GradeC
Sample reportexample-shop.com
Security score

72/100

/.env publicly reachable (HTTP 200)Error

What it means: This file often holds database passwords and API keys. Whoever downloads it needs no attack at all.

How to fix it: Block hidden files in the web server, then rotate every credential in the file.

# nginx
location ~ /\.(?!well-known) { deny all; }
No Strict-Transport-Security headerWarning

What it means: Browsers may still connect unencrypted on the first visit. On open Wi-Fi that connection can be redirected.

How to fix it: Set HSTS once every page runs on HTTPS.

# nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
DMARC with p=noneWarning

What it means: Forged emails in your name get reported, but still delivered.

How to fix it: Review the DMARC reports for two to four weeks, then switch to quarantine.

# DNS
_dmarc.example-shop.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example-shop.com"
Example with a made-up domain. The real report gives a recommendation for every finding; the configuration lines here are examples for nginx and DNS.

Check email security: SPF, DKIM and DMARC

Three DNS records decide whether strangers can send email in your name. The check reads all three – you only enter the website address.

SPF check

SPF (Sender Policy Framework) defines which servers may send email for your domain. The check looks for the TXT record starting with v=spf1. If it is missing, you get a warning: any server can then claim to send in your name.

Example record

your-domain.com  TXT  "v=spf1 include:_spf.google.com -all"

DKIM check

DKIM (DomainKeys Identified Mail) signs every outgoing email, the public key sits in DNS. The check looks for it under the selectors default, google and selector1. If your mail provider uses another one, it shows up as a note, not a fail.

Example record

google._domainkey.your-domain.com  TXT  "v=DKIM1; k=rsa; p=…"

DMARC check

DMARC tells receiving servers what to do with emails that fail SPF and DKIM. The check reads the record under _dmarc of your domain. Only p=quarantine or p=reject filters out forgeries, p=none just reports them.

Example record

_dmarc.your-domain.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@your-domain.com"
Check the domain only: SPF, DKIM & DMARC check Check your domain now

How your result is built

What the checks are based on: MDN: HTTP headers · BSI TR-02102 (TLS) · BSI TR-03108 (email transport) · RFC 7208 (SPF) · RFC 6376 (DKIM) · RFC 9989 (DMARC)

How the check runs

Read-only · 1 Origin

Is your website as secure as it should be? The check shows in seconds what every visitor – and every attacker – can see from the outside: HTTPS and certificate, security headers, cookies, exposed files and whether strangers can send email in your name. Read-only, no attacks, no login.

The check loads your homepage like a browser, follows redirects to the final address and rates every signal there on its own. On top come a TLS connection and public DNS lookups for CAA, SPF, DMARC and DKIM. Every check counts the same; there is no hidden weighting.

Score and ratings

4 levels
  • Passed: The signal is set or unremarkable.
  • Warning: A recommended protection is missing or too weak, such as a security header, a CSP with unsafe-inline, the HTTPS redirect, a cookie flag, DMARC with p=none or an outdated framework or CMS version.
  • Error: A fundamental problem: no HTTPS, a certificate that is invalid or expires within 7 days, an open directory listing, a publicly reachable .git or .env file, an active debug mode, a secret key in the page source or a software version with severe known vulnerabilities.
  • Note: Context only, such as missing COOP, CORP or COEP headers, no CAA record, external scripts without SRI or a missing security.txt.

The score is the share of passed checks among all rated checks. Notes don't count.

This gives your grade: A from 90 out of 100, B from 80, C from 65, D from 50, below that F. A single fail caps the grade at C.

Report and port check

instant + email

Instant result. Unlock the full report with detail findings via email.

  • Visible right away: your score and the number of passed checks, warnings, errors and notes.
  • With your email: every single check with its finding and recommendation, plus the full report by email.
  • Port check: 16 common ports, from web via SSH, FTP and mail to MySQL, PostgreSQL and Remote Desktop. We only open a connection, with no login and no request to the service.
  • You only get the port result if your email address belongs to the checked domain: in the email and, once you enter the code from that email, in the report too. It doesn't count toward the score.

What the check doesn't cover

Limits
  • Homepage only: we don't see subpages, login areas, checkout or APIs.
  • Versions only when the site reveals them: we check jQuery, Bootstrap, AngularJS, Vue, React and WordPress against OSV.dev, endoflife.date and WordPress.org. Shop, plugin and server versions are not checked for vulnerabilities.
  • Headers checked for common weaknesses: we spot unsafe-inline, unsafe-eval, wildcards and a short HSTS lifetime. That is not a full analysis of your CSP.
  • Email via DNS only: we read SPF and DMARC, and DKIM only under three common selectors. We don't check DNSSEC or actual delivery.

A good score means the basic configuration is right. What lies behind it only shows when someone looks at the application itself.

FAQ about the Security Check

Your question isn't here?

Ask directly

Is this a penetration test?

No. A penetration test attacks an application on purpose: logins, interfaces, permissions, inputs. The Security Check only reads what your site serves to every visitor and rates the configuration. No exploits, no credential attacks. On top of that comes a connect-only test of 16 common ports, whose result only goes to an email address on the checked domain.

What does my grade mean?

The grade sums up the score: A from 90 out of 100, B from 80, C from 65, D from 50, below that F. The score is the share of passed checks; notes don't count. A single fail, such as missing HTTPS or a publicly reachable .env file, caps the grade at C even if everything else is fine.

Do I need credentials?

No. We only fetch public addresses: your homepage over HTTPS and HTTP, robots.txt and /.well-known/security.txt. For /.git/HEAD, /.git/config, /.env and /.DS_Store we only look at the status code and file type and never read the content. For /server-status and /phpinfo.php we only check whether the typical page heading appears and store nothing. On top come a second homepage request with a foreign Origin header (CORS), a TRACE request to the homepage, a TLS connection on port 443 and public DNS lookups for CAA, SPF, DMARC and DKIM.

Do I still need a penetration test after a good result?

A good result shows that the public base configuration is right. Only a penetration test covers logins, APIs and business logic. For shops, customer portals and applications handling sensitive data we recommend one in addition.

Why email?

You see the score and the number of warnings and errors right away. Which items they are and how to fix them unlocks with your email, and the full report also arrives by email. Within one business day, a person from our team gets in touch once, with no sales pressure.

Can I check again after a fix?

Yes. Just run the check again; the result is there right away. Each domain can be checked up to 20 times per hour. If a CDN with page caching sits in front of your site, it may briefly still serve the old response.

What is a DMARC check?

A DMARC check reads your domain's DMARC record from DNS and checks whether it is set and how strict it is. Only with "quarantine" or "reject" are forged emails in your name actually filtered out. Our Security Check covers DMARC together with SPF and DKIM.

Can I check other people's websites?

The web check, yes: it only uses publicly reachable addresses and DNS records. We only send the port result to an email address on the checked domain, though, so for your-domain.com that would be info@your-domain.com, for example. It only appears in the report once you enter the code from that email.

What about my data?

Without unlocking, we store neither the URL nor the result in our CRM. Only when you unlock do we store your email, optional details such as name and phone, and the result there. If you have allowed statistics cookies, our product analytics records which URL you checked. See our privacy policy for details.

Are private networks scanned?

No. We block private, link-local, loopback and cloud metadata addresses, including when a redirect points there. Every request goes to the public IP we checked once.

From finding to fix

Most findings are configuration, not a rebuild. Depending on who runs your servers and DNS, there are three ways forward.

For admins, hosting providers and in-house IT

The report gives a recommendation for every finding. Headers, redirects and DNS records are often just a few lines of configuration. Then simply run the check again.

Check your website +49 (0) 2161 539 71 60
Profile picture of Slawa Ditzel, Executive Partner

Slawa Ditzel

Executive Partner

  1. You send the report or the domain
  2. We tell you which findings really count
  3. You get the effort and the right way forward

+49 (0) 2161 539 71 60info@next-levels.de

It matters legally, too: Art. 32 GDPR requires technical measures in line with the state of the art to protect personal data. Encrypted connections and a maintained server configuration are part of that. SPF, DKIM and DMARC also protect your brand from phishing in your name.

Related: Shopware audit · Legacy check · BFSG check · Hosting and scaling