Skip to content

Back to the catalog

https://github.com/akha-security/akca
github.comrepo

https://github.com/akha-security/akca

AKCA is an open-source, Go-based Dynamic Application Security Testing (DAST) scanner that combines HTTP and headless-browser crawling, JavaScript/AST analysis, API spec import (OpenAPI, GraphQL, gRPC, etc.), and adaptive active testing across a very broad set of vulnerability classes including SQL injection, XSS, SSRF, IDOR/BOLA, SSTI, JWT/OAuth flaws, race conditions, and cloud/CI exposure. It emphasizes evidence-oriented verification — replaying promising signals against baselines, negative controls, and OAST callbacks before promoting them to findings — and exports Burp-style HTTP evidence in HTML, JSON, CSV, Markdown, and SARIF reports. Positioned as a transparent, single-developer alternative inspired by but not claiming parity with Acunetix, Invicti/Netsparker, or Burp Suite Professional.

TL;DR Open-source Go DAST scanner that crawls, fingerprints, and evidence-verifies web/API vulnerabilities before reporting findings.
Document

What it is

AKCA (github.com/akha-security/akca) is a Go CLI DAST scanner, currently at v0.2.5, installed via go install github.com/akha-security/akca/engine/cmd/akca@latest (requires Go 1.25+) or downloaded from GitHub Releases with SHA256SUMS.txt and gh attestation verify provenance checks.

How it works

Execution is a staged pipeline: fingerprint/calibrate (tech, WAF, TLS, pacing) → discover attack surface (HTTP + persistent headless-browser crawl, JS/AST analysis, API specs, path fuzzing, 403-bypass probing) → model test candidates by method/content-type/param/auth context → plan adaptive probes prioritized by relevance → verify signals (baselines, negative controls, identity/state comparisons, OAST callbacks) → produce Burp-style evidence exports. Coverage gaps (budget cutoffs, skipped checks) are explicitly recorded rather than treated as clean results, and interrupted scans are not auto-resumed. Browser crawling can learn up to 32 passive third-party dependency hosts from resource tags/CSP automatically, but only allows GET/HEAD static-asset requests to them and never expands active scan scope that way.

Preconditions / Affected

Browser-backed checks require Chrome, Chromium, or Edge installed locally. Some authorization checks (BFLA, multi-tenant isolation) need multiple configured identities, not just one session. Rate-limit findings require both a configured threshold and a window_seconds value, otherwise results are "observations" not findings, and a mismatched window makes the check inconclusive. SQLi findings explicitly never rely on a bare 400 response or arithmetic-evaluation alone as proof.

What to do

Basic scan:

akca -u https://example.com

Targeted modules with HTML report:

akca -u https://example.com -m sql,xss,rce -f html -o report.html

API spec import:

akca -u https://api.example.com --api-spec ./openapi.yaml -m api

Bound resource use:

akca -u https://example.com --request-budget 5000 --time-budget 30m

or

akca -u https://example.com --requests-per-target 200

(--request-budget takes precedence over --requests-per-target; default crawl cap is 1,500 requests / 1,000 pages, module scanning itself is unbounded). Replay a stored finding for verification: akca replay --finding 42. By default reports mask recognized credentials; set redact_reports to false only when raw evidence is needed. Build-from-source verification before trusting a build:

go test ./... -count=1
go vet ./...
go run ./cmd/akca benchmark --strict
go run ./cmd/akca benchmark --complete-corpus

Caveats

Single-developer project, explicitly not claiming parity with Acunetix/Invicti/Burp Pro. Roadmap items not yet shipped include distinguishing browser-confirmed reflected XSS from true DOM-based execution, heuristic IDOR coverage for single-profile scans, and broader cloud-takeover fingerprinting — current detection in these areas should be treated as partial. Linked API/service subdomains are excluded from scope by default (--include-linked-api-subdomains required to include them).

Technologies named here

Techniques named here

  • Technology and WAF fingerprinting
  • HTTP and headless-browser application crawling
  • JavaScript and AST-assisted endpoint analysis
  • Hidden parameter discovery
  • Directory, file, backup, and administrative-path fuzzing
  • 403 Forbidden bypass testing
  • Reflection-context analysis
  • SQL injection
  • Reflected, DOM, stored-candidate, and blind XSS
  • Command injection and remote-code-execution
  • XML External Entity injection
  • Local File Inclusion and path traversal
  • Server-Side and Client-Side Template Injection
  • NoSQL, LDAP, and XPath injection
  • Insecure deserialization
  • CRLF injection and HTTP response splitting
  • Server-side JavaScript injection
  • React Server Components RCE
  • PDF generation injection and SSRF
  • AI/LLM prompt-injection
  • Second-order and delayed injection workflows
  • Broken Function Level Authorization
  • Route-authentication bypass
  • Broken and improper authentication
  • JSON Web Token security testing
  • OAuth and OpenID Connect flow security testing
  • Cross-Site Request Forgery
  • Rate-limit and bypass validation
  • Account-recovery weaknesses and account enumeration
  • Multi-tenant isolation checks
  • Cookie and session security testing
  • Session lifecycle and termination checks
  • Cross-Origin Resource Sharing misconfiguration testing
  • Open redirects
  • JavaScript prototype pollution
  • HTTP Parameter Pollution
  • Host-header injection and poisoning
  • HTTP request smuggling
  • WebSocket security and Cross-Site WebSocket Hijacking
  • GraphQL security and introspection exposure testing
  • gRPC and gRPC-Web protocol security testing
  • Reverse-proxy path confusion
  • JSONP callback abuse and XSSI exposure
  • Exposed Git repository and source-artifact discovery
  • Race conditions and concurrency flaws
  • Arbitrary file-upload testing
  • Mass assignment
  • Webhook signature and validation security testing
  • Parser differential analysis
  • Security headers and TLS/SSL configuration assessment
  • Vulnerable third-party component and known-CVE matching
  • IDOR
  • BOLA
  • SSRF
  • Path traversal