Scan Policies

A policy answers two questions: which checks run, and how hard the scanner pushes. Getting it right is the difference between a scan that finishes over lunch and one that is still going tomorrow.

What a Policy Is

A named selection of security checks, saved so you can reuse it. Vooki Pro ships built-in policies you cannot edit, and lets you create your own on top of them.

Built-in Policies

Five policies ship with Vooki Pro. The test count on each card is how many individual checks it runs, out of the 498 in the full catalogue:

Default is the widest, not Deep. Deep is a curated set of core categories that finishes faster; Default runs everything. If you are unsure which to pick, start with Default and narrow down only if scan time becomes a problem.

Creating a Custom Policy

• Open Policies under Config and click New.
• Name the policy, then tick the checks you want. Categories can be toggled as a group or opened up so you can select individual checks.
• Save. Your policy appears alongside the built-ins in every scan wizard.
• Custom policies can be edited and deleted; built-ins cannot.

Custom policies are how you handle the awkward cases: exclude the denial-of-service category when scanning production, drop the WordPress checks on an application that has never seen PHP, or build a tight regression policy that only re-tests the classes of bug you have been bitten by before.

The Check Catalogue

Vooki Pro exposes more than 480 individually selectable checks: 306 active attack checks across 26 categories, 177 version and CVE fingerprint checks, and three deep or passive analysis capabilities. The categories are:

• Injection Attacks (22) — SQL, NoSQL, blind SQL, XXE, XML, XPath, LDAP, command, SSTI, SSI, CRLF, host header, email, log, GraphQL, expression language, ORM, HTTP parameter pollution, code, XSLT and server-side JavaScript.
• Cross-Site Scripting (7) — reflected, stored, DOM-based, header-based, SVG, mutation XSS and HTML injection.
• Broken Access Control (9) — IDOR, function-level authorization, path traversal, forced browsing, privilege escalation, method-based bypass, horizontal access, path normalisation and method override.
• Authentication Failures (15) — credentials in URLs, HTTP basic over cleartext, default credentials, missing auth, brute-force exposure, user enumeration, JWT algorithm attacks, weak password policy and reset flaws.
• Cryptographic Failures (11) — deprecated TLS, TLS 1.0 and 1.1, certificate problems and expiry, weak ciphers, weak randomness, hardcoded keys, padding oracle, ECB mode and data unprotected at rest.
• SSRF & Related (6), Insecure Deserialization (6) — Java, PHP, Python pickle, .NET, JSON and XML.
• Information Disclosure (43) — stack traces, directory listings, source code and source maps, exposed .git, backups, API keys, PII, phpinfo, Swagger exposure, server version leakage and more.
• Business Logic (7) — price and quantity tampering, workflow bypass, race conditions, integer handling, coupon abuse and rule bypass.
• API Security (12) — the OWASP API Top 10 classes.
• Security Headers (19), Cookie Security (8), CSRF (4), Session Management (7).
• File Security (8) — upload abuse, type bypass, traversal, LFI, RFI, polyglots and zip slip.
• HTTP Protocol (12) — request smuggling, h2c upgrade, verb tampering, open redirect, cache poisoning and rapid reset.
• Web Cache Deception (3), Prototype Pollution (3), Encoding Attacks (4), DNS Security (3).
• OAuth / OIDC / SAML (16), Denial of Service (7).
• LLM Security (5) — prompt injection, indirect injection, data exfiltration, resource exhaustion and training-data poisoning.
• CVE-Class Attacks (5) — Shellshock, PHP-CGI RCE, Heartbleed, Log4Shell and Spring4Shell.
• Client-Side Security (28) — clickjacking, CORS, postMessage abuse, service worker hijacking, tabnabbing, WebSocket issues, and vulnerable versions of jQuery, AngularJS, Bootstrap, React, Vue, lodash and others.
• Configuration (36) — debug modes, verbose errors, exposed admin panels, dangerous HTTP methods, cloud storage exposure, Spring actuators, container metadata, plus WordPress, Joomla and Drupal specifics.
• Version and CVE checks (177) — outdated CMS, JavaScript libraries, frameworks and runtimes, servers and proxies, databases, business applications, and DevOps infrastructure.
• Deep & Passive Analysis (3) — CVE database expansion of detected versions, WordPress active probing against a vulnerability database of around 17,000 entries, and ThreatLens passive response analysis.

Speed and Throttling

Speed is set on the Policy step of the scan wizard rather than baked into the policy, so the same policy can run gently against production and hard against staging:

• Stealth — 2 parallel requests, 2 second delay.
• Normal — 5 parallel requests, 500 ms delay.
• Aggressive — 10 parallel requests, no delay.

Setting concurrency, delay or requests-per-second explicitly overrides the preset; where two settings conflict, the larger effective delay wins.

Choosing a Policy

• First scan of an unfamiliar host — Quick, to see what you are dealing with without committing hours.
• Regular testing — Standard.
• Pre-release or pre-audit — Deep, run overnight.
• Production — a custom policy with the destructive and denial-of-service categories removed, at Stealth speed.
• CI pipeline — a tight custom policy that finishes inside your build timeout.