VeriFalcon security posture
VeriFalcon is built to inspect route integrity conservatively. This page explains the current product posture around crawl safety, credential handling, and deployment responsibility in concrete terms.
The crawler is designed around GET-style navigation and conservative safety boundaries rather than arbitrary browser interaction or destructive test automation.
Key Takeaways
Start here, then expand detailed sections as needed.
Security-Relevant Facts About The Product Today
The crawler is designed around GET-style navigation and conservative safety boundaries rather than arbitrary browser interaction or destructive test automation.
Authenticated crawling is supported, but the intended posture is minimized credential retention and scan-scoped use unless the operator explicitly chooses otherwise.
The current product posture assumes the environment owner is responsible for the deployment, domain, TLS, access control, and surrounding infrastructure hardening.
Security-Relevant Public Surfaces
Crawl-safety model
VeriFalcon is designed to answer a read-only question: what breaks when a real user clicks through this site or app? That means the crawler is intentionally conservative about actions that could mutate state.
The product is not positioned as a destructive test runner. It is designed around safe navigation, route discovery, and issue classification.
- GET-style navigation is the intended default crawl behavior
- logout, delete, payment, and similar destructive patterns are treated as safety boundaries
- authenticated crawling is supported without turning the product into a free-form interaction bot
Credential handling
Authenticated crawling is a first-class workflow, so credential handling matters. The current posture is to minimize retention and use credentials only for the active scan flow unless the operator explicitly chooses otherwise.
That is a practical posture for QA and route validation work because it acknowledges the need for auth while still treating credential persistence as the exception rather than the default.
Deployment responsibility
VeriFalcon is currently deployed and operated by the environment owner. Domain ownership, TLS termination, infrastructure hardening, backups, monitoring, and access control remain part of the deployment operator's responsibility.
This page is intentionally honest about that boundary so teams understand what the product handles directly and what still belongs to the deployment environment around it.
Best fit and not-best-fit for security expectationsVeriFalcon's security value is in safe crawl behavior and boundary clarity, not in replacing dedicated security tooling.
- best fit: teams needing conservative read-only crawl validation on technical routes
- best fit: environments where auth-aware route checks need explicit protected/blocked classification
- not best fit: organizations expecting full vulnerability scanning or continuous threat detection
- not best fit: teams needing managed infrastructure security ownership from the product vendor
Operational evidence snapshot (March 29, 2026)Security copy is anchored to present workflow and deployment behavior.
- auth fields are first-class in the JavaScript scan entry workflow
- results model separates protected, blocked, broken, and scanner-error outcomes
- deployment ownership boundaries remain explicit in runbook and trust-page messaging
Related Pages
Continue with pages that map to adjacent use cases and comparisons.