Most website owners assume their site is secure because it loads over HTTPS and nothing has gone visibly wrong. That's the equivalent of assuming your house is safe because the front door locks. In reality, your website broadcasts dozens of security signals that attackers read like a menu. Here are 10 concrete checks you can run right now — each one tests for a real vulnerability class that's actively exploited.
1. Check Your TLS Certificate and Configuration
Open your browser's developer tools, click the padlock icon, and inspect the certificate. Verify that it's valid, not expiring within 30 days, and issued to the correct domain. But don't stop there — the certificate itself is only part of the story.
What matters more is the TLS configuration behind it. Your server might support outdated protocol versions (TLS 1.0 and 1.1 are deprecated and vulnerable to known attacks like BEAST and POODLE) or weak cipher suites that make encryption crackable. You can test this using tools like the SSL Labs server test, which grades your configuration and flags specific weaknesses. Anything below an A rating means there are concrete improvements to make.
A properly configured TLS setup uses TLS 1.2 or 1.3 only, strong cipher suites with forward secrecy, and a certificate from a trusted authority with at least 2048-bit RSA or 256-bit ECC keys.
2. Inspect Your HTTP Security Headers
Open your browser's developer tools, navigate to the Network tab, click on the document request, and review the response headers. You're looking for these critical headers:
- Content-Security-Policy: Controls which scripts, styles, and resources can load. Without it, any injected script runs freely.
- Strict-Transport-Security: Forces HTTPS for all future visits, preventing protocol downgrade attacks. The value should include
max-ageof at least 31536000 (one year). - X-Content-Type-Options: Should be set to
nosniffto prevent MIME-type confusion attacks. - X-Frame-Options: Prevents your site from being embedded in iframes on other domains, blocking clickjacking attacks.
- Referrer-Policy: Controls what URL information leaks to third parties when users click links on your site.
- Permissions-Policy: Restricts which browser APIs (camera, microphone, geolocation) are available to your page and embedded content.
Each missing header corresponds to a specific, proven attack technique. If you're missing more than two, your site has meaningful gaps.
3. Test for Information Disclosure
Look at your response headers for Server and X-Powered-By headers that reveal your software stack and version numbers. A header like Server: nginx/1.18.0 tells an attacker exactly what software you're running and whether known CVEs apply. Similarly, check your error pages — trigger a 404 and see if the default error page reveals framework names, file paths, or version numbers.
This information costs you nothing to remove but gives attackers a significant head start in identifying exploitable weaknesses.
4. Verify Your DNS Records
Your DNS records are public, and several of them are security-critical. Use a DNS lookup tool to check:
- SPF record: A TXT record starting with
v=spf1that defines which servers can send email as your domain. Without it, anyone can spoof your email address. - DMARC record: A TXT record at
_dmarc.yourdomain.comthat tells receiving servers what to do with emails that fail authentication. A policy ofp=noneprovides monitoring but no enforcement —p=rejectis the goal. - DKIM record: Cryptographic signing for your outbound email. Without it, email authentication is incomplete.
If you're missing SPF and DMARC records, attackers can send convincing phishing emails that appear to come from your domain. This is actively exploited against businesses of every size.
5. Check Cookie Security Attributes
Log into your site, open developer tools, and navigate to the Application or Storage tab. Examine each cookie and look for three critical flags:
- Secure: Ensures the cookie is only sent over HTTPS. Without it, the cookie transmits in plaintext on any HTTP request.
- HttpOnly: Prevents JavaScript from reading the cookie. Without it, XSS attacks can steal session tokens directly.
- SameSite: Controls whether the cookie is sent on cross-site requests. Without it, CSRF attacks can use the authenticated session.
Session cookies missing any of these attributes represent a concrete session hijacking risk.
6. Test HTTPS Redirect Behaviour
Type your domain with http:// explicitly and see what happens. Your site should redirect to HTTPS immediately with a 301 (permanent) redirect, not a 302 (temporary). If it loads over HTTP at all — even briefly before redirecting — that initial unencrypted request can be intercepted on untrusted networks.
Additionally, test http://www.yourdomain.com, http://yourdomain.com, and any subdomain variations. Each one should redirect to HTTPS. A single HTTP endpoint that serves content without redirecting is a valid attack surface.
7. Look for Mixed Content
Your page might load over HTTPS, but if it includes scripts, stylesheets, or images over HTTP, that's mixed content. Mixed active content (scripts and stylesheets) is particularly dangerous because an attacker who can intercept HTTP traffic can modify the script in transit and execute arbitrary code in the context of your HTTPS page.
Modern browsers block mixed active content by default, but mixed passive content (images) still loads and can leak information. Check the browser console for any mixed content warnings.
8. Review Your CORS Policy
If your site has an API, send a request with an Origin header set to a domain you don't control. If the response includes Access-Control-Allow-Origin matching that origin (or set to *) along with Access-Control-Allow-Credentials: true, your API is vulnerable to cross-origin data theft. Any website can make authenticated requests to your API and read the responses.
This is one of the most commonly misconfigured settings in modern web applications, and automated scanners frequently miss it.
9. Check for Open Ports and Unnecessary Services
Your web server should expose exactly the ports it needs — typically 80 (HTTP, redirecting to HTTPS) and 443 (HTTPS). Additional open ports may indicate database interfaces, admin panels, development tools, or other services that shouldn't be publicly accessible. Tools like Nmap can scan your domain for open ports from an external perspective, showing you what the rest of the internet can see.
Common findings include exposed database ports (3306 for MySQL, 5432 for PostgreSQL, 27017 for MongoDB), Redis on port 6379, and SSH on port 22 with password authentication enabled.
10. Test for Clickjacking
Create a simple HTML page that embeds your site in an iframe. If it loads, your site is vulnerable to clickjacking — an attack where a transparent overlay tricks users into clicking buttons on your site while they think they're interacting with something else. This can be used to trick users into changing account settings, making purchases, or granting permissions they didn't intend.
The fix is the X-Frame-Options header (set to DENY or SAMEORIGIN) or a Content-Security-Policy with a frame-ancestors directive. Both instruct the browser to refuse to render your site inside a frame on an untrusted domain.
ShieldReport runs all 10 of these checks — and more — against your domain in under 30 seconds, mapping every finding to the specific attack it prevents so you can prioritise fixes with full context.