Scan types

What you'll need

• ·Public URL
• ·Ownership verification (DNS TXT or HTML file)

How to use it

1. Add the URL below and submit.
2. Open the target's Verification tab and follow the DNS TXT or HTML-file flow.
3. Click Run a full scan. Each sub-check shows live status while it runs.

What we test

• ·TLS chain + protocol versions + cipher inventory
• ·DNS records + DNSSEC
• ·Email DNS: SPF / DKIM / DMARC
• ·Security headers: HSTS, CSP, XFO, XCTO, Referrer-Policy, Permissions-Policy, COOP / COEP / CORP
• ·Subresource Integrity audit on cross-origin script + style tags
• ·Mixed content, cookie flags, redirect chain audit
• ·Sensitive paths probe (SPA-safe)
• ·Subdomain inventory via crt.sh + dangling CNAME / takeover detection
• ·Tech fingerprint + JS library CVE match
• ·Open-redirect detection + passive SSRF surface enumeration
• ·Dangerous HTTP method audit via OPTIONS
• ·API key leak scan across response body + headers
• ·On Growth+: Nuclei 8000+ templates

What we never do

• ·No brute-force, no random fuzzing, no DoS
• ·Read-only HTTP only - no form submission, no destructive payloads

What you'll need

• ·Public URL
• ·Ownership verification
• ·Optional: bearer token or session cookie on the Credentials tab
• ·Optional: OpenAPI spec under Credentials to unlock API authorization probes

How to use it

1. Add the URL and verify ownership.
2. On the target's Credentials tab, paste a non-admin bearer / cookie for authenticated checks.
3. If you have an OpenAPI spec, upload it under the OpenAPI section.
4. Run a full scan. The authenticated runs surface logged-in BFLA / IDOR / rate-limit findings the public scan can't see.

What we test

• ·Everything in Website tier
• ·Authenticated baseline (private headers, cookie flags behind login)
• ·BFLA + rate-limit + ZAP active rules (Growth+)
• ·OpenAPI BOLA / BFLA / mass-assignment when spec is attached (Growth+)
• ·IDOR cross-account test when two test accounts are configured
• ·CSRF / OAuth / WebSocket / file-upload / HTTP smuggling / cache poisoning / session-fixation detectors
• ·DOM-XSS canary probe via Playwright

What we never do

• ·Never brute-forces the login page
• ·Never submits user-modifying actions outside the OpenAPI mass-assignment probe (no DELETE, ever)

What you'll need

• ·API base URL
• ·Ownership verification
• ·Strongly recommended: OpenAPI 3 / Swagger 2 spec uploaded on the Credentials tab
• ·Optional: bearer token for primary identity + alt bearer for BOLA / BFLA tests

How to use it

1. Add the API base URL and verify the host.
2. Upload your OpenAPI spec on the Credentials tab (JSON or YAML, up to 4 MiB).
3. Add a bearer token. For BOLA / BFLA add a second non-admin token under the IDOR section so the worker can cross-check authorization.
4. Run a full scan. The Schemathesis + apiauthz checks become visible after the spec lands.

What we test

• ·API endpoint discovery (openapi.json, swagger.json, /redoc, GraphQL introspection)
• ·API key leak scan + excessive data exposure detector (sensitive field names in JSON)
• ·Rate-limit header advisory (RateLimit-* / X-RateLimit-* / Retry-After)
• ·API health / actuator / debug endpoint enumeration
• ·API versioning hygiene (/api/v1..v4 multi-version exposure)
• ·JWKS endpoint hygiene (rotation + key strength + alg=none guard)
• ·Schemathesis property-based fuzz when OpenAPI is reachable
• ·JWT signing weakness probes
• ·Webhook signature replay-attack tests
• ·BOLA / BFLA / mass-assignment when an OpenAPI spec + bearer tokens are uploaded

What we never do

• ·DELETE is never invoked
• ·POST / PUT / PATCH only fired by the mass-assignment probe with canary fields

What you'll need

• ·GitHub repository URL (HTTPS)
• ·For private repos: a fine-scoped GitHub personal access token added on the Credentials tab
• ·Optional: Web3 add-on ($299 / month) to unlock Slither Solidity / Vyper smart-contract scanning

How to use it

1. Add the repository URL.
2. For private repos, paste a read-only PAT on the Credentials tab; we encrypt it at rest with AES-256-GCM.
3. If the repo carries .sol / .vy smart contracts, enable the Web3 add-on on /billing so Slither runs on every scan.
4. Run a full scan. The deep-scan step clones the repo into a scratch dir and unrolls every analyzer in parallel.

What we test

• ·Repo metadata: SECURITY.md, Dependabot state, archived flag, staleness
• ·Regex-based secret scan on the latest snapshot
• ·Growth+: osv-scanner recursive across every lockfile (npm, yarn, pnpm, pip, poetry, go.mod, Cargo, Gemfile, composer)
• ·Growth+: gitleaks across full git history
• ·Growth+: Trivy filesystem scan (vulnerabilities + IaC misconfiguration + secrets)
• ·Growth+: Semgrep CE with the p/default pack for pattern-based SAST
• ·If repo contains K8s manifests: Kubescape against the YAML
• ·If repo contains Android / iOS source: mobsfscan against the project tree
• ·With Web3 add-on: Slither 80+ Solidity / Vyper detectors (reentrancy, tx.origin, weak randomness, locked ether, arbitrary-send, suicidal contracts, integer overflow, ERC compliance)
• ·With Web3 add-on + deployed address pinned: on-chain Slither over Etherscan-verified source + NFT audit (ERC-721 / 1155 metadata classification, IPFS pinning probe, ERC-2981 royalty check)

What we never do

• ·We never push to the repository or open issues / PRs
• ·Clone is shallow + scratch; nothing is retained after the scan

What you'll need

• ·kubectl access to the cluster
• ·Output of kubectl get all -A -o yaml (or any subset you want audited)

How to use it

1. Run kubectl get all -A -o yaml > snapshot.yaml against your cluster.
2. Optionally include CRDs: kubectl get RoleBinding,ClusterRoleBinding,NetworkPolicy,PodSecurityPolicy -A -o yaml >> snapshot.yaml.
3. Open Cloud integrations -> Kubernetes snapshot and upload the YAML.
4. Findings surface under the auto-created Kubernetes target.

What we test

• ·Kubescape NSA framework: privileged pods, hostPath mounts, capabilities, RBAC misconfiguration
• ·Workload-level findings linked back to the namespace + resource
• ·CIS benchmark-aligned controls where the snapshot has enough signal

What we never do

• ·No outbound connection from our worker to your cluster
• ·Snapshot is processed in-memory then discarded; raw YAML is encrypted at rest

What you'll need

• ·Built APK (Android) or IPA (iOS) - release artifact, not debug build
• ·Maximum 50 MiB per upload

How to use it

1. Build the APK with ./gradlew assembleRelease or the IPA from Xcode Archive.
2. Open Cloud integrations -> Mobile app and pick Android or iOS.
3. Give the app a short label (used for the auto-created target name).
4. Upload the binary. The worker decompiles with apktool (Android) or unzips the IPA, then runs the full mobile detector battery.

What we test

• ·MASVS + OWASP Mobile Top 10 rule pack via mobsfscan
• ·AndroidManifest analysis: cleartext traffic, debuggable, allowBackup, dangerous permissions, exported components, deep links
• ·Info.plist analysis (iOS): NSAllowsArbitraryLoads ATS bypass, privacy permission claims, custom URL schemes
• ·Third-party SDK fingerprint: 30+ Android SDKs / 25+ iOS frameworks (Firebase, Facebook, Stripe, AdMob, AppsFlyer, Sentry, Datadog, Intercom, ...)
• ·Trivy filesystem scan against the decompiled tree (React Native / Cordova / native library CVEs)
• ·Hard-coded secrets in resources / strings.xml / Info.plist
• ·Insecure storage flags (world-readable, weak crypto, plaintext)

What we never do

• ·We never sign or repackage the binary
• ·Binary is encrypted at rest; the bytea column is locked from the dashboard role and only the worker reads it

What you'll need

• ·AWS: read-only IAM access key + secret (or assumed-role STS)
• ·Azure: read-only Service Principal (clientID + tenantID + clientSecret)
• ·GCP: read-only Service Account JSON

How to use it

1. AWS: create an IAM user with the AWS-managed SecurityAudit policy. Generate an access key.
2. Azure: register an App, grant Reader role at the subscription scope, create a client secret.
3. GCP: create a Service Account, grant viewer + iam.securityReviewer, download the JSON key.
4. Open Cloud integrations -> pick the provider and paste the credential. We encrypt at rest with AES-256-GCM.
5. Run a scan from the auto-created cloud target.

What we test

• ·Prowler CIS + best-practice audit (200+ checks)
• ·AWS only: CloudFox attack-surface enumeration (IAM privesc, public assets, secrets in user data)
• ·Public buckets / databases / load balancers, stale keys, weak encryption, missing MFA
• ·RBAC over-permission, exposed serverless endpoints, cross-account trust risk

What we never do

• ·Read-only IAM only. We never request write permissions.
• ·No changes are made to your cloud resources.