Project methodology
How the toolbox thinks
Cyber Toolbox is intentionally narrow: small tools, bounded checks, clear evidence, and defensive guardrails. The goal is to make security posture easier to discuss without pretending that automated checks replace a real assessment.
Defensive scope
Cyber Toolbox is designed for public, authorized checks that help owners understand basic web security posture. It does not crawl sites, brute force services, exploit findings, or attempt authentication bypass.
Network safety
Every server-side URL check is routed through an SSRF guard. The guard resolves hostnames before fetches, blocks private and reserved address space, rejects localhost-style names, and re-applies the same checks after redirects.
Rate limiting
API routes use a small in-memory per-IP limiter. It is intentionally simple for a portfolio deployment and can be swapped for Vercel KV or Upstash Redis if the project needs durable shared limits.
Severity model
Findings are graded as pass, info, warn, or fail. Fail means a missing or dangerous control. Warn means a weakness, ambiguity, stale value, or risky configuration. Info points out useful optional improvements without penalizing the target heavily.
Evidence-first reports
Reports favor concrete evidence: the exact header, policy field, certificate detail, response behavior, or parsed token claim that led to the finding. Recommendations are written as remediation guidance instead of generic warnings.
Known limitations
These tools provide focused checks, not a full security assessment. A clean report does not prove an application is secure. Network errors, CDN behavior, redirects, and intentionally unusual policies can also affect results.