What is website security?
Website security covers every measure that stops outsiders from stealing data, altering content or misusing the site for their own ends. Small websites are rarely picked out on purpose. Attackers send automated programs across the web that hunt for known gaps and exploit them straight away. A hijacked site may then spread malware, redirect visitors to phishing pages or send spam.
For site owners, the consequences are real. Browsers and Google warn people about the site, and customers lose trust. If personal data leaks, legal obligations follow as well.
A widely used point of reference is the OWASP Top 10 list from the Open Worldwide Application Security Project. Germany's Federal Office for Information Security (BSI) also refers to it. In the 2025 edition, Security Misconfiguration, meaning wrong or missing settings, ranks second. Back in the 2021 edition, this category was still in fifth place. Other categories include Broken Access Control, Software Supply Chain Failures, Injection and Authentication Failures.
How does a security check work?
An external check needs no access to your server. It opens the website, reads the web server's responses and tests well-known addresses. That way it sees the site roughly as an attacker would. It examines encryption, HTTP headers, publicly accessible files, software version details, forms and the domain's email records.
Such a scan has limits. It knows neither your passwords nor your server settings, and it does not understand business logic. Whether a customer could open someone else's invoices by changing an order number is something it usually misses. 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 by hand, deliberately and with your permission.
Only test websites that belong to you or for which you have written permission. Scanning other people's sites can count as an attempted attack. If your website is run by a hosting provider or an agency, clarify beforehand whether scans are allowed. For legal questions, a specialist lawyer can help. This is general information, not legal advice.
The key building blocks
Encryption with HTTPS
The connection between browser and server should always be encrypted; the BSI recommends transport encryption for web applications as a matter of principle. Make sure you have a valid certificate, a clean redirect from http:// to https:// and that no file still loads over HTTP. If the browser shows "Not secure", one of these points is usually missing.
Up-to-date software
Many gaps affect CMSs, themes and plugins that have not been updated for a long time. Keep the core, extensions and PHP version current. Delete extensions you no longer use, because even a deactivated plugin stays on the server.
Secure logins
The login page is a popular target for automated password guessing. Use strong passwords and two-factor sign-in for administrators. Remove old user accounts and protect the login against repeated failed attempts.
No exposed files or secrets
Files such as .env, a .git folder or backups do not belong in the public directory. A .env file often contains database passwords and API keys. Your JavaScript must not contain secret keys either, as every visitor can read that code.
Headers and email records
Security headers give the browser rules, for example to use HTTPS only or to load approved scripts only. The SPF, DKIM and DMARC records make it harder for fraudsters to forge emails using your sender address. Both areas have their own topic pages: security headers and email security.
Common mistakes
- A .env file, a backup or a .git folder can be opened in the browser.
- Unused plugins stay installed and receive no updates.
- The server reveals version numbers, for example through the X-Powered-By header.
- Form error messages display technical details.
- After a finding, the file is deleted while the credentials it contained stay the same.
- A clean scan report is treated as proof that the website is secure.
How to check
A current browser and a little time are enough for a first overview. Open your website, press F12 and switch to the "Network" tab. Reload the page and click the first document. Under "Response headers" you can see what the server sends. In the "Console" tab, mixed content warnings point to files that still load over HTTP. From a terminal, the command curl -I https://example.com returns the same headers.
Next, try addresses such as /.env, /.git/config or /backup.zip on your domain. An error page with 404 or 403 is good; any visible content or download is a serious gap. Check the update status in your back end and ask your hosting provider which version you are running.
Fix findings by risk: first remove exposed secrets and change every affected password, then update software, secure logins, complete HTTPS and add headers. Make a backup before each change and test forms, shop and login afterwards. Repeat the check after major updates and otherwise at regular intervals, for example once a month.
Articles on this topic
Frequently asked questions
Do small websites really get attacked?
Yes. Most attacks are automated and scan huge numbers of websites for known gaps, regardless of their size.
Is a security check the same as a penetration test?
No. A check tests known points automatically from the outside. In a penetration test, specialists attack the application deliberately and by hand.
What should I do if Google flags my website as dangerous?
Look at the "Security issues" report in Search Console, remove the malicious code, update all software and change your passwords. You can then request a review there.
How often should I check my website?
After every major update and otherwise regularly, for example once a month.
Sources: OWASP Top 10 (editions 2021 and 2025) by the Open Worldwide Application Security Project; Germany's Federal Office for Information Security (BSI); Google Search Console "Security issues" report.