Frontend
NativeHTML, CSS, JavaScript modules, and browser APIsSecurity Posture
Keep the public frontend small, inspectable, and dependency-light.
This page explains why the site favors native browser APIs, static pages, and local helpers over large client dependencies for its public vulnerability workflow.
Inputs
Localmost tools transform pasted data in the browserLookups
Scopedbackend-assisted tools should be clearly labeledReview
Visiblenew dependencies need an explicit reason and test pathPosture
What dependency-free means here
Small public attack surface
Fewer client dependencies mean fewer package updates, supply-chain surprises, and framework-specific runtime paths to audit.
Readable behavior
Most UI behavior lives in local modules that can be searched, reviewed, and tested with the release prep scripts.
Local-first tools
Formatters, parsers, calculators, and draft helpers should run in the browser unless a lookup genuinely needs the backend.
Clear exceptions
DNS, mail-auth, and similar network lookups can use backend assistance, but those pages should label the runtime boundary.
No hidden guarantees
Dependency-light does not prove vulnerability-free. It only makes the public frontend easier to inspect and reason about.
Review before adding packages
Any new dependency should name the user value, security tradeoff, maintenance owner, fallback behavior, and release check that will catch regressions.
Maintainer rule: add a dependency only when it removes real risk or complexity. For simple parsing, formatting, scoring, and page behavior, prefer local modules first.