Website Security Checklist: Is Your Site Actually Protected?

What is web security? It's the set of practices and controls that protect your website from unauthorized access, data breaches, and abuse. Most discussions of web security focus on the code and infrastructure layer: HTTPS configuration, SQL injection prevention, dependency patching, access control. These are genuinely important. This checklist covers a different layer — the traffic-layer threats that standard website security checklists almost never mention.

If you've completed the basics (HTTPS, patched dependencies, no obvious injection vulnerabilities), this checklist tells you what's likely still missing.

The traffic-layer checklist

1. Do you know what percentage of your traffic is automated?

If you haven't measured this, you don't know whether your baseline traffic includes 5% bots or 60% bots. Both are real ranges we see across different site types. Most web analytics platforms (Google Analytics, Mixpanel) filter bot traffic from their numbers by default — which means they're actively hiding the signal you need. Server-level traffic analysis or a dedicated bot detection tool in monitor mode will show you the real picture.

2. Is your login flow protected against credential stuffing, not just rate-limited by IP?

Per-IP rate limiting on login is table stakes and provides minimal protection. Professional credential stuffing operations use residential proxy networks that rotate through thousands of IP addresses per campaign. A 100-requests-per-hour per-IP limit with a 100,000-IP proxy pool means 10 million login attempts per hour — all well under your per-IP threshold. Protection that actually works requires behavioral detection per session, independent of IP address.

3. Do you have visibility into scraping activity?

Scrapers deliberately stay under rate-limit thresholds. A price intelligence scraper checking your catalog every 4 hours from rotating residential IPs may not trigger a single alert on a standard monitoring setup — but it's effectively giving your competitor a real-time feed of your pricing strategy. Without specific scraping detection, you won't know it's happening until you notice the business impact downstream.

4. Is your DDoS protection limited to your CDN's default network-layer coverage?

CDN-included DDoS protection handles volumetric bandwidth attacks. It doesn't handle Layer 7 application-layer DDoS: HTTP floods targeting your search endpoint, checkout API hammering, login form brute force at scale. These attacks send valid HTTP requests that CDN scrubbing passes through, exhausting your application servers while leaving your network bandwidth headroom untouched. Protecting your website from hackers at the application layer requires behavioral detection beyond what CDN defaults provide.

5. Are your APIs protected with the same scrutiny as your web application?

Mobile apps expose API endpoints that are effectively public — determined attackers extract them from app binaries within hours of a release. APIs that were designed with the assumption that only your official app would call them frequently lack the rate limiting and behavioral protection that your web application has. This discrepancy is a common entry point for credential stuffing, data scraping, and account enumeration attacks.

Common website security vulnerabilities checklists miss

Unprotected APIs treated as "internal." Internal doesn't mean inaccessible. Any API your mobile app calls can be called by anything else. The API security vulnerability here isn't a code flaw — it's missing protection at the traffic layer.

No bot traffic visibility. You can't defend against threats you can't see. Most teams discover they have a bot traffic problem through business impact (inflated checkout failure rates, pricing data appearing on competitor sites, account lockouts) rather than through proactive monitoring. By the time the business impact is visible, the problem has typically been ongoing for months.

DDoS coverage gaps at Layer 7. The gap between "we have DDoS protection" (CDN network-layer) and "we're protected against DDoS" (including application-layer) is where Layer 7 attacks operate. This gap is real, exploitable, and commonly overlooked until an incident demonstrates it.

How to protect your website from hackers, practically

This checklist is specifically about traffic-layer protection — it's a complement to standard website security practices (HTTPS, vulnerability scanning, patching), not a replacement for them.

Practical next steps:

1. Deploy bot detection in monitor mode to establish your traffic baseline — no blocking, just visibility.

2. Review the results: what percentage of your traffic is automated, and which endpoints are being targeted?

3. Enable protection in the categories with the highest-priority business impact first — typically login (credential stuffing) and pricing/catalog (scraping).

4. Add API-level protection to match what your web application has.

The goal is closing the visibility gap first, then making informed blocking decisions based on real data from your traffic.

For a full overview of what traffic-layer protection covers, see website protection: bots, DDoS, scraping, and API security.