The twelve-point outside-in checklist
- HTTPS everywhere. Every page loads over HTTPS, and plain HTTP redirects to it.
- Valid, current certificate. It matches your domain, is not close to expiry and is renewed automatically.
- Modern TLS only. Support TLS 1.2 and 1.3 and disable older protocol versions.
- HSTS. Send
Strict-Transport-Securityso browsers refuse to downgrade to HTTP. - Security headers. Set
Content-Security-Policy,X-Content-Type-Options,Referrer-Policy,Permissions-Policyand a clickjacking control such asframe-ancestors. - SPF, DKIM and DMARC. Authenticate your email so your domain cannot be spoofed. See the email authentication guide.
- No exposed databases or admin ports. Nothing like MySQL, PostgreSQL, MongoDB, Redis or RDP answers on the public internet.
- Patched software. Your web server, CMS, plugins and libraries are on supported versions with no known vulnerabilities.
- No leaked credentials. Your domain’s email addresses do not appear in breach corpora, or affected passwords are already reset.
- Clean reputation. Your domain and IP are not on blocklists or threat-intelligence feeds.
- No public cloud storage by accident. Buckets and blobs named after your business are private unless intentionally public.
- A privacy notice and a grievance contact. Visible, reachable and current. See the DPDP checklist.
What to fix first
| Priority | Fix | Typical effort |
|---|---|---|
| 1 | Close exposed databases and remote-access ports | Under an hour with your host or IT provider |
| 2 | Publish SPF, DKIM and DMARC (start at p=none) | Half a day including monitoring setup |
| 3 | Renew and automate certificates; enforce HTTPS and HSTS | One to two hours |
| 4 | Update CMS, plugins and server software | Half a day; schedule recurring updates |
| 5 | Reset breached credentials and enable multi-factor authentication | One to two hours |
| 6 | Add security headers | One to two hours; test CSP in report-only mode first |
How to run these checks
You can verify each item by hand, or all at once:
- By hand: browser developer tools show headers and certificates, DNS lookups show SPF, DKIM and DMARC, and a port scan from outside your network shows exposed services.
- Automatically: a free RiskPulse scan runs ten parallel checks, scores the result from 0 to 850 and writes a plain-English fix plan with a Hindi summary. The method is published on the CyberScore engine page.
Website security questions
How do I check whether my website is secure?
Run an outside-in scan against your domain. It checks the certificate and TLS configuration, security headers, email authentication, exposed ports, software versions with known vulnerabilities, leaked credentials and reputation, which are the signals an attacker would look at first. A free RiskPulse scan covers all of these in about 45 seconds.
Is it legal to scan my own website?
Scanning a domain you own or are authorised to test is normal security hygiene. RiskPulse uses only public, non-intrusive signals and sends no authenticated traffic, but you should still scan only domains you are responsible for.
Which ports should never be open to the internet?
Databases (MySQL 3306, PostgreSQL 5432, MongoDB 27017, Redis 6379, SQL Server 1433) and remote-desktop access (RDP 3389) should not be reachable from the public internet. Administrative access such as SSH should be restricted to known addresses or placed behind a VPN.
What is the single most useful fix for most small businesses?
Publishing SPF, DKIM and DMARC and enforcing multi-factor authentication on email and admin accounts. Business email compromise and credential theft cause more loss than rare, sophisticated attacks.
How often should I run a website security check?
Monthly as a baseline, plus after any change to hosting, DNS, plugins, certificates or email providers. Continuous monitoring catches expiring certificates and new exposures between manual checks.