Available scan types
Shieldome offers four scan types. You select the type when starting a scan from the dashboard or via the API.
| Type value | Checks included | Typical duration |
|---|---|---|
vuln | OWASP Top 10 vulnerability checks only | 30–60 s |
perf | Performance metrics only | 10–20 s |
both | Vulnerability + Performance | 45–90 s |
api | API endpoint security checks | 20–40 s |
vuln, perf, both, api).
Vulnerability scan (vuln)
Runs all OWASP Top 10 (2021) checks. This is the core of Shieldome — it covers 100+ individual checks across 10 risk categories:
- Broken Access Control (sensitive paths, directory listing, open redirects)
- Cryptographic Failures (SSL/TLS, HSTS, HTTPS redirect, certificate validity)
- Injection (SQL injection, XSS reflection, path traversal, SSTI, CRLF)
- Insecure Design (robots.txt leaks, backup files, source exposure)
- Security Misconfiguration (security headers, CORS, server info, debug endpoints)
- Vulnerable and Outdated Components (version headers, CMS/framework detection, CVE matching)
- Authentication Failures (cookie security, session exposure, JWT analysis)
- Software and Data Integrity Failures (Subresource Integrity)
- Security Logging Failures (verbose errors, stack traces)
- SSRF (URL parameter analysis)
Performance scan (perf)
Measures how fast and well-optimized your site is:
- DNS lookup time — how long to resolve the domain
- TTFB (Time To First Byte) — server response latency
- Page size — total HTML response size
- HTTP/2 support — whether the server speaks HTTP/2
- HTTP/3 support — QUIC / HTTP3 detection
- Compression — gzip/brotli enabled
- Caching headers — Cache-Control, ETag, Expires presence
- Performance grade — composite score across all metrics
Full scan (both)
Runs both vulnerability and performance checks in a single pass. Recommended for most use cases — you get a complete picture of both security posture and performance health.
API scan (api)
Optimised for REST API backends that don't serve a browser UI. The API scan skips checks that rely on rendered HTML (e.g. SRI, clickjacking headers) and instead focuses on checks that matter for machine-to-machine endpoints:
- Authentication controls — does the endpoint reject unauthenticated requests? Are API keys accepted over HTTP?
- Injection — SQLi and path-traversal indicators via query parameters
- Security headers — CORS policy (especially permissive
Access-Control-Allow-Origin: *), HTTPS enforcement - Information disclosure — verbose error messages, stack traces, server version strings in responses
- SSRF indicators — URL parameters that may be proxied server-side
- TLS quality — cipher suites, certificate validity, HSTS
api type when your target is an API base URL (e.g. https://api.example.com). For full-stack apps that expose both a web UI and an API, both gives the most complete coverage.Custom IP override
All scan types support an optional Target IP field. When set, scan requests are sent directly to that IP while the Host header is preserved. This is useful for:
- Testing a staging server before DNS cutover
- Scanning a server that isn't publicly DNS-resolvable
- Verifying a specific server in a load-balanced cluster
Target URL: https://example.com
Target IP: 10.0.1.42 # requests go to this IP, Host: example.com
Excluded paths
You can provide a list of URL paths to skip during scanning. One path per line, relative to the target:
/admin /logout /api/internal