Have you checked your site for security holes?

Websites are rarely broken into by geniuses — automated systems continuously scan the public web for known, preventable weaknesses, and many compromises exploit exactly those. The problem with "have you checked for security holes?" is that it's too vague to act on. So here is a concrete scope to check, and a cadence to keep it checked.

Where the holes actually are

• Exposed or outdated software. CMS core, plugins, themes, and libraries with published vulnerabilities — plus admin panels, phpinfo pages, .git folders, or backups left reachable in the web root.
• Server and application configuration. HTTPS not enforced or mixed content; security headers and cookie attributes missing where they apply (a Content-Security-Policy protects rendered pages, not a JSON API — configure each control for the responses it's relevant to); verbose errors leaking paths; unintended directory listings.
• Identities and permissions. Default or reused admin passwords, missing MFA, weak throttling on login, password-reset and other sensitive operations — and, separately, excessive rights: file permissions, service accounts and database users with more than they need.
• Every input path — not just visible forms. Input also arrives through URLs, cookies, headers, APIs, webhooks, imports, and previously stored data. The classics: injection from mishandled input, uploads accepted too permissively, forms without server-side validation, and cookie-authenticated state changes without CSRF protection.
• Third-party dependencies. Composer/npm packages, embedded scripts, external widgets and build tooling — running on your server, in visitors' browsers, or in your deployment pipeline, any of them can carry flaws or supply-chain risk.

These five areas are a starting framework, not the whole surface: include every hostname and API, domain and DNS control, deployment accounts and secrets, sessions, and the places sensitive data is stored or logged.

Fix it on a cadence, not once

1. Find — an authorized, non-destructive scan plus a manual look. Scan only what you own or are authorized to test, and treat scanner output as leads, not proof: expect false positives, and know that unauthenticated scans miss protected routes, logic flaws and source-level bugs. Behind a reverse proxy, a public TLS test grades the edge — audit the proxy-to-origin hop and direct origin exposure separately.
2. Prioritize — by exploitability, exposure, required privileges, affected data and business impact. Public reach raises urgency, but a high-impact flaw behind a login can still come first.
3. Fix — remediate the top items, not just the easy ones. For uploads, that means: allow only required types and sizes, never trust the supplied filename or MIME type, generate storage names, store outside the web root or on an isolated host, and serve as non-executable content. For cookie-authenticated actions: the framework's CSRF defense, validated server-side, with no state changes over GET.
4. Recheck — confirm each fix worked and nothing regressed, then schedule the next pass.

Day-to-day patching and account hygiene is its own discipline (covered separately) — here the point is to audit the whole surface on a repeatable schedule, and after every release, advisory or incident, rather than trusting routine.

Takeaway: Audit the real attack surface — software, config, identities, inputs, dependencies, and everything attached to them — and run it as a find-prioritize-fix-recheck cycle triggered by the calendar and by events, not a one-time scan.

What to do

1. Inventory your surface — the five areas plus every hostname, API, deployment system and data store. You can't secure what you haven't listed.
2. Run an authorized scan and header/TLS checks; verify findings by hand, and audit the origin separately if a proxy fronts the site.
3. Handle input safely: parameterized queries for data values, allowlists for dynamic identifiers, context-appropriate output encoding, CSRF protection on cookie-authenticated state changes, and hardened uploads.
4. Protect accounts and apply least privilege — unique passwords and MFA on privileged accounts; separately, minimal rights for roles, files, services and database users.
5. Prioritize, fix, and recheck — on a calendar, after significant changes, and whenever an advisory names something you run.
6. Keep protected, versioned backups outside production, with separate access and tested restores, so you can recover if something does get through.