akca

Evidence-oriented DAST scanner in Go that crawls web apps and APIs, then runs adaptive SQLi, XSS, RCE, SSRF, and auth checks with replayable proof.

Why AKCA

Many scanners crawl an application and then send a broad payload set to every discovered endpoint. That strategy can create unnecessary traffic, trigger defensive systems, and produce weak signals that require substantial manual triage. AKCA takes a more contextual approach: it first learns about the target, models the discovered attack surface, and then selects tests according to the technology stack, parameters, authentication state, WAF behavior, and available verification capabilities.

AKCA is designed to:

• Discover hidden routes, JavaScript-loaded endpoints, undocumented parameters, API operations, and access-controlled paths before active testing.
• Fingerprint technology and WAF behavior, then calibrate request pacing and safe payload transformations to the observed target.
• Allocate work across endpoint, method, parameter, and module combinations instead of blindly applying every payload everywhere.
• Pause and recover from rate limiting or host-level blocking, within configured scan and time limits.
• Replay promising signals with baselines, negative controls, state checks, identity comparisons, or OAST callbacks before promoting them to findings.
• Preserve request, response, payload, confidence, and proof-policy context so results can be investigated rather than accepted on faith.

The goal is not to exhaust or overwhelm the target. It is to find real weaknesses with deliberate requests and useful evidence.

AKCA does not claim feature or detection parity with mature commercial platforms such as Acunetix, Invicti/Netsparker, or Burp Suite Professional. Those products are built by experienced teams over many years. AKCA is independently maintained by one developer in available personal time, inspired by established security tools and shaped by original ideas and community feedback. The current priority is a simple, useful, and transparent scanner. A graphical interface is planned when the engine is sufficiently stable and dependable.

_{AKCA v0.2.4 scan session with live engine status, resource telemetry, and confirmed findings.}

Installation

Go install

Requires Go 1.25 or newer.

Prebuilt binaries

Download your build from GitHub Releases. Releases include SHA256SUMS.txt for checksum verification.

On Linux or macOS, make the downloaded file executable. For Linux x64:

On Windows, rename the download to akca.exe and run .\akca.exe --help in PowerShell. The examples below assume akca is available on your PATH.

Browser-backed checks require Chrome, Chromium, or Edge.

Usage

Use AKCA only on systems you own or have permission to test. Replace the example URL with your authorized target.

Start a scan

The default profile is full. To save an HTML report:

Choose specific checks

Run SQL injection, XSS, and server-side injection checks, including SSTI:

Run passive checks:

Passive scans still send requests for discovery and inspection.

Use an authenticated session

Supply a session cookie:

Or an authorization header:

Some authorization checks require additional identities or state configuration beyond a single session.

Import an API definition

Discovery supports OpenAPI/Swagger, RAML, Postman, HAR, GraphQL, WSDL, protobuf, and AsyncAPI inputs, including supported ZIP bundles. Testing coverage depends on the imported protocol and operation.

Inspect traffic through a proxy

Run akca --help for all available options.

Use akca -h for concise everyday help, or akca --help for the complete option reference. Scan targets must be supplied explicitly with -u or --url.

Scan profiles

Select a profile with -m, or combine several with commas.

Execution depends on discovered endpoints, configuration, available verification capabilities, and scan limits. See FEATURES.md for the full capability guide.

How AKCA works

AKCA uses a staged pipeline so later checks can benefit from facts learned earlier:

1. Fingerprint and calibrate — identify technologies, server behavior, WAF signals, TLS posture, and safe request pacing.
2. Discover the attack surface — combine HTTP crawling, a persistent browser session, JavaScript analysis, API definitions, path fuzzing, parameter discovery, and 403 bypass observations.
3. Model test candidates — group endpoints by method, content type, parameters, authentication context, and likely vulnerability class.
4. Plan adaptive probes — prioritize relevant payload families, preserve work for later endpoints, and apply target-aware encoding or pacing when defensive behavior is observed.
5. Verify signals — compare baselines and controls, replay promising results, inspect state or identity changes, and correlate OAST callbacks where required.
6. Produce evidence — export findings with Burp-style HTTP transactions, payloads, classifications, confidence, proof status, and reproduction guidance.

Coverage is explicit. A skipped, failed, budget-limited, or unfinished target is recorded as incomplete coverage; it is not silently treated as a clean security result.

Security testing coverage

The following list describes implemented discovery engines and security-test families. Individual checks run only when the discovered surface, scan profile, configuration, safety policy, and verification prerequisites make them applicable. A listed capability is not a guarantee that every variant of a vulnerability will be detected.

Scope and scan limits

Set a total request budget and maximum duration:

Or calculate the module budget from discovered URL/method combinations:

AKCA distributes bounded module budgets across modules, URLs, and parameters. Unused allocations move forward to later work. A positive --request-budget takes precedence over --requests-per-target.

By default, the module scan has no request quota. Budget interruptions are reported as incomplete coverage. Interrupted targets are not automatically resumed when later work returns unused budget. No budget setting guarantees detection of every vulnerability.

Linked API/service subdomains are outside the default target scope. To include linked subdomains under the same root:

Why a Full Scan takes longer

AKCA's default Full Scan is designed around coverage and evidence quality, not the shortest possible completion time. Its runtime is therefore not directly comparable to tools that stop after a shallow HTTP crawl or report a vulnerability from a single response difference.

A comprehensive run may take longer because AKCA:

• Maintains a browser session for client-rendered routes and inspects JavaScript, including lazily loaded application chunks.
• Replays promising results with controls before promoting them to findings, reducing false positives caused by generic errors, unstable pages, and WAF responses.
• Performs identity-, state-, and callback-aware checks when a module requires stronger proof.
• Respects target pacing, retries, request budgets, and out-of-band observation windows instead of treating speed as the only success metric.

Scan duration also depends on application size, response latency, authentication flows, defensive controls, and the configured scope. For faster feedback, select only the relevant modules with -m or apply explicit crawl, request, and time budgets. Increase rate and concurrency only when the authorized target can safely handle the additional traffic. A shorter scan is not necessarily a more complete scan.

Reports

Choose an output format with -f and a file path with -o:

Supported formats: HTML, JSON, Markdown, CSV, and SARIF. Each invocation starts a new scan.

HTML reports are self-contained and include the AKCA logo, risk and severity summaries, vulnerability statistics, structured finding details, and expandable HTTP evidence. Request and response tabs support a combined view, full-content expansion, and copying. Where a finding preserves a matching response value, AKCA highlights it in yellow, helping you locate a reflected payload or exposed secret. Passive secret findings retain an excerpt around the match.

Depending on the module, findings include:

• Recorded HTTP requests and responses.
• Payloads and cURL reproduction commands.
• Confidence, verification observations, and proof-policy status.
• CWE and OWASP mappings.

Timing findings, missing headers, and external callbacks may have no response text to highlight. Their verification context supplies the relevant evidence.

When the scanner stored a complete raw transaction, the report preserves it exactly. Older or structured-only evidence is rendered in a conventional Burp-style HTTP layout with a request line, ordered headers, a header/body separator, and standard HTTP response reason phrases. If the transport capture limit truncated a response, the report says so explicitly; it never presents the stored portion as the unavailable complete response.

Replay a stored finding:

Reports mask recognized credentials by default. Raw stored evidence is preserved for replay. Set redact_reports to false in scan configuration, or use redact=false on the report API, only when raw exports are needed. Review reports before sharing: automatic masking cannot recognize every application-specific secret.

Crawl and proof configuration

The crawler retains one browser session throughout each crawl phase, including cookies and browser storage. It explores explicit non-form tabs and expandable panels; it does not auto-fill or submit forms. Browser requests still obey scope and request budgets. For required third-party static dependencies, configure exact hostnames separately:

This permits only GET/HEAD script, stylesheet, image, font and media requests to those hosts, stripping credential and custom headers. It does not add those hosts to the active scan scope or permit cross-origin API calls. Blocked browser dependencies produce coverage-gap events.

Discovered URLs are retained even when they cannot be visited. A crawl that exhausts its budget with queued work produces a partial scan and a nonzero CLI exit code. Module preflight messages distinguish missing identity/state policies from configured verification capabilities.

Unconfigured rate-limit checks produce observations, not vulnerability findings. A configured threshold proof also requires window_seconds; if the requests do not fit inside that window, the check is inconclusive. SQLi does not treat a 400 response or arithmetic evaluation alone as proof. New vendor-specific SQL errors in 400/422 responses must pass the replay and control verification path.

What's new in v0.2.4

• Preserve complete stored raw HTTP requests and responses in reports, including long bodies, repeated headers, and trailing whitespace.
• Render structured-only traffic in a conventional Burp-style layout with standard request headers, content length, and HTTP reason phrases.
• Add an offline AKCA-branded HTML report, a vulnerability summary table, Request/Response/Both views, full-content controls, and print-safe evidence.
• Rebuild the startup display as a Lipgloss-based Scan Session panel with target emphasis, system and RAM details, and an active-state indicator.
• Replace the scan ETA with a continuously updating elapsed timer and show friendly module names with in-place Running-to-Completed transitions.
• Keep repetitive browser dependency and coverage diagnostics in verbose output while preserving them in scan metadata and reports.

See CHANGELOG.md for release details.

Support the mission

AKCA does not accept sponsorships or personal donations. Code contributions, testing, documentation, and thoughtful feedback are always welcome.

Türkiye'den destek olmak isteyenler için

Projeye maddi olarak destek olmak istiyorsanız, bana göndermek yerine Mehmetçik Vakfı, AFAD, Türk Kızılay veya Çocuk Hizmetleri Genel Müdürlüğü aracılığıyla desteklenen güvenilir sosyal yardım çalışmalarından birine bağış yapmanızı rica ediyorum. Mümkünse bağışınızı kızım Akça Aktaş adına yapın. Bağıştan sonra X üzerinden @caneraktas_ hesabına mesaj göndermeniz beni gerçekten çok mutlu eder.

For supporters outside Türkiye

If you would like to support the project financially, please donate to a reputable charity in your country that helps children, disaster-affected communities, veterans, or people in urgent need. When possible, make the donation in the name of my daughter, Akça Aktaş. You are welcome to share it with me on X at @caneraktas_; knowing that this project inspired a helpful act would mean a great deal to me.

Development

Build from source:

On Windows, use -o ../akca.exe for the executable name.

Run checks from the engine directory:

The benchmark measures its observed corpus. For implementation details and verification limitations, read the architecture guide and verification audit.

Contributions are welcome. Read CONTRIBUTING.md and the Code of Conduct before opening a pull request. Report vulnerabilities in AKCA through SECURITY.md.

License

Apache License 2.0 · Copyright 2026 AKHA Security contributors.