ShieldReport
HomeWhat We CheckToolsWikiCompareRoadmapPricingBlogSign InRun Free Scan
Run Scan
HomeWhat We CheckToolsWikiCompareRoadmapPricingBlogSign In
15 June 20257 min read

What Makes a Website Insecure: An Attacker's Perspective

Understand how attackers evaluate a website's security posture — the signals they look for, the misconfigurations they exploit, and why the padlock icon means less than you think.

securityattack surfacereconnaissancethreat modelling

Implementation Example

Use this as your remediation starting point

This animated snippet mirrors the style of fixes used in generated reports.

nginx

When a threat actor evaluates a target, they don't start with sophisticated zero-days. They start with the cheapest, fastest techniques: reading publicly available signals that reveal how seriously a site takes security. Most websites broadcast their weaknesses in plain text. Here's what attackers see when they look at your site.

The First 30 Seconds: Passive Reconnaissance

An attacker's first step costs zero effort. They request your homepage and read the HTTP response headers. In those headers, your server tells them everything they need to know:

  • A Server: Apache/2.4.51 header reveals the exact software version — and whether known CVEs apply.
  • An X-Powered-By: Express header narrows the attack surface to Node.js-specific vulnerabilities.
  • A missing Content-Security-Policy header signals that XSS payloads will likely execute without resistance.
  • No Strict-Transport-Security means SSL stripping attacks are on the table.

This isn't advanced hacking. It's reading metadata that your server volunteers with every single request.

TLS Configuration as a Security Signal

Attackers check TLS configuration because it's a reliable proxy for overall security maturity. A site still supporting TLS 1.0 is almost certainly running outdated software elsewhere. A certificate nearing expiration suggests manual processes and a team that's stretched thin — meaning other security tasks are likely deferred too.

More critically, weak TLS configuration enables concrete attacks. Support for deprecated cipher suites opens the door to BEAST, POODLE, and Lucky13. A missing HSTS header means the initial HTTP connection can be intercepted and downgraded before HTTPS ever kicks in.

DNS Records: The Overlooked Attack Surface

Your domain's DNS records are public. Attackers query them routinely. What they're looking for:

  • No SPF record: They can send email as your domain. Phishing campaigns using your legitimate domain bypass spam filters because there's no policy saying they shouldn't.
  • No DMARC record: Even if you have SPF, without DMARC enforcement, receiving servers won't reject spoofed emails. Attackers know this and specifically target domains with p=none or missing DMARC.
  • Dangling DNS entries: CNAME records pointing to decommissioned services are subdomain takeover opportunities. If blog.yourdomain.com points to a deleted Heroku app, an attacker can claim that hostname and serve content under your domain.

Cookie Configuration Tells a Story

Cookies without security attributes are a gift to attackers. A session cookie missing the HttpOnly flag can be read by any JavaScript running on the page — including injected XSS payloads. Missing Secure means the cookie transmits over plain HTTP on any non-HTTPS request. Missing SameSite enables cross-site request forgery.

Attackers don't need to find all three missing. Any single gap is enough to build an exploit chain.

Information Disclosure: The Free Intelligence

Error pages are surprisingly chatty. A stack trace on a 500 error reveals the framework, version, file paths, and sometimes database connection strings. A robots.txt listing /admin, /staging, and /api/internal is essentially a map of high-value targets.

These aren't obscure findings. They appear on the majority of websites because developers focus on functionality, not on what their infrastructure reveals to anyone who asks.

The Compound Effect

No single misconfiguration is usually catastrophic on its own. But attackers chain them. A missing CSP + an XSS vector + a cookie without HttpOnly = full session hijacking. A leaked server version + an unpatched CVE + no WAF = remote code execution. Security is only as strong as the weakest combination.

ShieldReport evaluates your domain the way an attacker would — checking every signal, header, and record — then shows you exactly what's exposed and how to fix it before it's exploited.

Related Reads

8 min read

Open Ports and Your Attack Surface: What Nmap Reveals About Your Site

8 min read

Why Your Website Needs a Security Audit in 2025 (Before Attackers Do It for You)

6 min read

ShieldReport Is Free During Launch — Here's What You Get

Run Your Own Audit

Generate a developer-ready security report in under two minutes.

Try Free ScanView Sample Report
ShieldReport

Website security scanning and reporting for developers, teams, and agencies.

ShieldReport - Security reports done in minutes which developers understand | Product Hunt

Product

  • Free Security Scan
  • What We Check
  • Pricing
  • Sample Report

Resources

  • Security Blog
  • FAQ
  • Website Security Checklist
  • CSP Guide

Topics

  • Security Headers
  • TLS Configuration
  • OWASP Top 10
  • Vulnerability Scanning

© 2026 ShieldReport. All rights reserved.

Run Free ScanPricingBlogSitemapRSS Feed