In short: an external security check looks at your website the way an attacker sees it: encryption, HTTP headers, files anyone can download, software versions, forms and email settings. You can test much of this yourself with a browser. An automated scan finds typical weaknesses, but it cannot promise that a website is secure. Only check sites that belong to you or that you have permission to test.
Why you should check your website's security
Small websites are rarely picked out on purpose. Attackers let automated programs run across the internet looking for known security holes: an old plugin, an open directory, a weak password on the login page. If such a program finds a gap, it exploits it. Afterwards the site may spread malware, send visitors on to phishing pages or send out spam.
As the site owner, you feel the consequences directly. Browsers and Google warn people about the site, customers lose trust, and if personal data leaks, legal obligations follow. A regular website check lowers this risk. It shows you the weak spots before someone else finds them.
What an external security check covers
An external security check needs no access to your server. It opens the website, reads the web server's responses and tests well-known addresses. These areas are part of it:
HTTPS and TLS
The connection between browser and server should always be encrypted. Germany's Federal Office for Information Security (BSI) recommends transport encryption for web applications as a general rule. A scan checks whether the SSL certificate is valid and whether it expires soon, whether old protocol versions are still allowed and whether every http:// address redirects cleanly to https://. When the browser shows "Not secure", this encryption is usually missing, or part of the page still loads over HTTP.
Security headers
Certain HTTP headers let the server tell the browser how to behave. Examples are Strict-Transport-Security (allow HTTPS only), Content-Security-Policy (load approved scripts only) and X-Content-Type-Options. Without them, an attacker has an easier time with cross-site scripting (XSS) or clickjacking. What each header does is explained in our article Security headers explained simply.
Exposed files and directories
A common mistake on small websites: files sit in the public folder that have no business being there. Scanners request specific URLs, for example these:
https://example.com/.env https://example.com/.git/config https://example.com/backup.zip https://example.com/wp-config.php.bakA .env file often holds database passwords and API keys. From an open .git folder, it is sometimes possible to download the complete source code. If one of these addresses returns content instead of an error message, you have a serious security hole.
Access keys in JavaScript
Anything the browser loads can be read by every visitor. If a secret key for a payment service, an email delivery service or a database appears in the JavaScript code, it is public. A scan searches the loaded scripts for the typical patterns of such keys. Public keys that are meant for the browser are not a problem here.
Outdated software and plugins
Many systems give away their version: in the source code, in file names or in a header such as Server: Apache/2.4.x or X-Powered-By: PHP/8.x. A scanner compares this information with known vulnerabilities. With WordPress, TYPO3 and other CMS, this mainly concerns extensions that have gone a long time without updates.
Forms and login
Contact forms, search fields and logins accept input. A check looks at whether forms submit over HTTPS, whether the login is protected against many failed attempts and whether error messages reveal technical details. Deeper tests for SQL injection or XSS belong in a penetration test.
Email settings of the domain
The domain itself is part of security too. Without SPF, DKIM and DMARC, fraudsters can send emails using your sender address. A check queries the DNS records and reports gaps. How to set them up is described in the article SPF, DKIM and DMARC.
OWASP Top 10:2025: the biggest risks for web applications
The Open Worldwide Application Security Project (OWASP) publishes a list of the most important security risks for web applications. It is also referenced by the BSI. The 2025 edition names these ten categories:
- Broken Access Control: users reach data or functions that are not meant for them.
- Security Misconfiguration: wrong or missing settings, such as exposed files or missing headers.
- Software Supply Chain Failures: problems in third-party components such as libraries, plugins or build tools.
- Cryptographic Failures: weak or missing encryption.
- Injection: smuggled-in code, for example SQL injection or cross-site scripting.
- Insecure Design: flaws that already exist in the concept of an application.
- Authentication Failures: weaknesses in the login, such as missing protection against password guessing.
- Software or Data Integrity Failures: code or data is taken over without being checked.
- Security Logging and Alerting Failures: attacks go unnoticed because nobody logs them or raises the alarm.
- Mishandling of Exceptional Conditions: the application reacts insecurely to errors and edge cases.
One change stands out: Security Misconfiguration has risen from 5th place in the 2021 edition to 2nd place. These are exactly the mistakes an external scan finds well. For small websites, supply chain and authentication also matter, because they concern plugins and passwords.
What you can check yourself
For a first overview you need no special tool. A current browser and a little time are enough.
Step by step with the developer tools
- Open your website and press F12. The developer tools open.
- Switch to the "Network" tab and reload the page.
- Click the first entry, which is the HTML document. Under "Response headers" you can see what the server sends along.
- Look for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and Referrer-Policy.
- In the "Console" tab, check for warnings about mixed content. They point to files that still load over HTTP.
If you use a terminal, one command gives you the same result:
curl -I https://example.comThe response lists all headers of the home page. If it shows something like X-Powered-By: PHP/7.4.3, the server is revealing a version that stopped receiving security updates long ago.
Test for exposed files
Open the addresses from the example above for your own domain in the browser. An error page (404 or 403) is good. Any response that shows content or downloads a file is bad.
Check your update status
Log in to the back end of your CMS and see whether the core, the theme and all plugins are up to date. Delete extensions you no longer use; a deactivated plugin still sits on the server. Ask your hosting provider which PHP version is running. If you need help with WordPress, read our article on choosing a WordPress agency.
Services from Mozilla and Google
On MDN, Mozilla offers the HTTP Observatory. It rates a website's security headers and explains what is missing. In Google Search Console you will find the "Security issues" report. There, Google tells you if it has detected malware, hacked content or phishing on your website.
Limits of an automated scan
An automated website check only sees what can be reached from outside. It does not know your passwords, cannot see server settings and cannot understand business logic. Whether a customer can call up other people's invoices by changing an order number is something a scanner usually misses. Flaws like this fall under Broken Access Control and need a person who tests for them on purpose.
Scans also produce false alarms and overlook some things. A clean report therefore only means that the points it checked were fine. For online shops, portals with user accounts or applications that handle customer data, a penetration test is worth adding. In one, specialists attack the application manually with your permission and go much deeper.
Only scan your own sites
A security scan sends many targeted requests to a server. Under German law, doing this to someone else's website can be treated as an attempted attack and have legal consequences. So only check websites that belong to you or for which you have written permission from the operator. This also applies if your website is hosted by a provider or an agency: clarify beforehand whether scans are allowed. The above is general information, not legal advice. If you are unsure, ask a lawyer who specialises in this area.
The order in which to fix gaps
After the check you usually have a long list. Work through it by risk:
- Exposed secrets: if a .env file, a backup or a key is publicly accessible, delete the file immediately. Then change every affected password and key, because you cannot know who has already copied them.
- Known vulnerabilities: update your CMS, plugins and PHP. Many holes were closed by an update long ago.
- Access: strong passwords, two-factor login for admins, and removal of old user accounts.
- Encryption: HTTPS everywhere, redirects from HTTP, no mixed content.
- Headers: start with X-Content-Type-Options and Referrer-Policy, then roll out HSTS in stages, and finally add a Content-Security-Policy in test mode.
- Email: set up SPF, DKIM and DMARC for the domain.
- Version details: hide headers such as X-Powered-By so the server reveals less about itself.
Make a backup before every change, and afterwards test whether forms, shop and login still work. Repeat the check after every major update and otherwise at regular intervals, for example once a month.
Summary
An external security check uncovers the most common mistakes on small websites: missing encryption, missing headers, exposed files, old plugins and unprotected email domains. You can check much of this yourself with a browser and curl. Applications that handle customer data also need a manual test. You will find more basics on our topic page Website Security.
Sources: OWASP, "OWASP Top 10:2025" (owasp.org/Top10/2025); BSI (Germany's Federal Office for Information Security), information on web applications; MDN Web Docs, HTTP headers and HTTP Observatory; Google Search Console Help, "Security issues" report.