Cybersecurity
What a Website Security Review Should Actually Cover
A plain-language look at how CATALYST reviews modern websites and products for weak spots, risky assumptions, and the issues that can turn into real trust problems.
A security review should answer a simple question: where can this product lose trust, control, or data? When we audit a modern website or web application, we are less interested in sounding technical and more interested in finding the places where assumptions break under real use.
Scope before scanners
We start with scope, because a useful review needs context: what matters to the business, what kind of users exist, and what would actually hurt if it went wrong. Without that, scans create noise and nobody trusts the outcome.
- Threat model: who benefits from abusing this product?
- Assets: accounts, admin panels, file uploads, webhooks, PII.
- Trust boundaries: browser ↔ edge ↔ origin ↔ third parties.
Reconnaissance that matters
We map routes, cookies, storage, third-party scripts, and API shapes. Source maps left public, verbose error pages, and forgotten staging hosts often hand us more than a scanner’s first pass.
What we look for early
- Admin or debug surfaces reachable without the expected role.
- JWT or session handling that trusts client-controlled claims.
- CORS that reflects arbitrary origins with credentials.
- Upload endpoints without type, size, or auth constraints.
Authn, authz, and the boring middle
Most serious findings are authorization bugs: user A can read user B’s resource because the API checks “logged in” and not “owns this id.” We exercise horizontal and vertical privilege paths deliberately — not only the happy UI flow.
Injection and misconfiguration
We test classic injection where inputs meet queries, templates, or shell boundaries. On JAMstack and serverless apps, misconfiguration is equally common: public buckets, permissive CSP that still allows script gadgets, and webhook receivers that trust unsigned payloads.
Modern stacks failed closed less often than teams expect. Defaults are convenient. Convenience is not a control.
Findings that get fixed
Every issue we report includes reproduction steps, impact in plain language, severity, and a concrete remediation. We prefer pairing with the engineering team for a retest rather than vanishing after delivery. An audit that cannot become a patch is theatre.
| Severity | Example | Typical response |
|---|---|---|
| Critical | Auth bypass on account data | Patch before next release window |
| High | Stored XSS in authenticated app | Fix + CSP tighten + retest |
| Medium | Missing rate limit on login | Harden + monitor |
| Low | Verbose server error leakage | Sanitize responses |
If you want CATALYST to run this process on your product, start with a brief at /contact — include stack, environments, and what “sensitive” means for your business.
Related
