akca - AKCA Advanced Web Security Scanner

项目说明

<p align="center">
<img src="logo.png" alt="AKCA logo" width="320">
</p>

<h1 align="center">AKCA</h1>
<p align="center"><strong>Ad Web Security Scanner</strong></p>
<p align="center">Disco. Test web applications. Inspect the e.</p>

<p align="center">
<a href=" src=" alt="CI"></a>
<a href=" src=" alt=" v0.2.7"></a>
<a href=" src=" alt="Go 1.25 or newer"></a>
<a href="LICENSE"><img src=" alt="Apache License 2.0"></a>
</p>

<p align="center">
<a href="#installation">Installation</a> ·
<a href="#usage">Usage</a> ·
<a href="#how-akca-works">Workflow</a> ·
<a href="#scan-profiles">Profiles</a> ·
<a href="#security-testing-co">Co</a> ·
<a href="#reports">Reports</a> ·
<a href="#support-the-mission">Support</a> ·
<a href="FEATURES.md">Features</a> ·
<a href="CHANGELOG.md">Changelog</a>
</p>

AKCA is an open-source, e Dynamic Application Security Testing (DAST) scanner written in Go. It combines HTTP and browser-assisted crawling, Ja analysis, API imports, adapti testing, passi, and replayable e in one command-line workflow.

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 defensi, 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 a capabilities.

AKCA is designed to:

Disco routes, Ja endpoints, undocumented parameters, API operations, and access-controlled paths before acti.

Fingerprint technology and WAF behavior, then calibrate request pacing and safe payload transformations to the obser.

Allocate work across endpoint, method, parameter, and module combinations instead of blindly applying every payload e.

Pause and recover from rate limiting or host-le, within configured scan and time limits.

Replay promising signals with baselines, negati, state checks, identity comparisons, or OAST callbacks before promoting them to findings.

Preser, response, payload, confidence, and proof-policy context so results can be in rather than accepted on faith.

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

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 de in a 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.

<p align="center">
<img src="docs/assets/scanner.png" alt="AKCA scanner running against a local security testing lab" width="760">
<br>
_{AKCA v0.2.7 scan session with li status, resource telemetry, and confirmed findings.}
</p>

Installation

Go install

Requires Go 1.25 or newer.

installs the newest tagged release, not an untagged commit on main. To test the current de branch, use . If an older binary still runs, compare command -v akca with go en (or $(go en)/bin) and refresh the shell command cache with hash -r. akca -- prints the embedded release build commit/date when a.

<details>
<summary>Command not found? Configure your PATH.</summary>

For the default Go installation, add the Go binary directory to your current terminal's PATH.

Linux / macOS

Add that line to your shell configuration to keep it across sessions.

Windows PowerShell

For future sessions, add the same directory to your user Path en . If you configured GOBIN, use that directory instead.

</details>

Prebuilt binaries

Download your build from GitHub Releases. Releases include SHA256SUMS.txt and GitHub build-pro attestations. a downloaded binary with gh attestation <binary> -R akha-security/akca.

| Platform | Architecture | Asset |
| --- | --- | --- |
| Linux | x64 / ARM64 | akca-linux-amd64 / akca-linux-arm64 |
| macOS | Intel / Apple Silicon | akca-darwin-amd64 / akca-darwin-arm64 |
| Windows | x64 | akca-windows-amd64.exe |

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 a on your PATH.

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

Usage

Use AKCA only on systems you own or ha 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 ser injection checks, including SSTI:

Run passi:

Passi 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 co depends on the imported protocol and operation.

Inspect traffic through a proxy

Run akca --help for all a options.

Use akca -h for concise e 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.

| Profile | Checks |
| --- | --- |
| full | All enabled active and passi; the default |
| sql | SQL and NoSQL injection |
| xss | Reflected, stored, DOM, and blind XSS; related client-side checks |
| rce | Command injection, SSTI, deserialization, and related checks |
| api | API exposure, BOLA/IDOR, BFLA, mass assignment, and token checks |
| graphql | GraphQL schema and operation checks |
| ssrf | SSRF, XXE, and related out-of-band checks |
| auth | Authentication, authorization, CSRF, and cookie/header checks |
| passive | Metadata, TLS, security headers, secrets, and component analysis |
| fuzz | Paths, exposed artifacts, tra, and related checks |

Execution depends on discovered endpoints, configuration, a 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, ser, WAF signals, TLS posture, and safe request pacing.
2. Discover the attack surface — combine HTTP crawling, a persistent browser session, Ja analysis, API definitions, path fuzzing, parameter discovery, and 403 bypass obser.
3. Model test candidates — group endpoints by method, content type, parameters, authentication context, and likely class.
4. Plan adapti — prioritize relevant payload families, preserve work for later endpoints, and apply target-aware encoding or pacing when defensi is observed.
5. signals — compare baselines and controls, replay promising results, inspect state or identity changes, and correlate OAST callbacks where required.
6. Produce e — export findings with Burp-style HTTP transactions, payloads, classifications, confidence, proof status, and reproduction guidance.

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

Security testing co

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

<details>
<summary><strong>1. Discovery, crawling, and analysis engines</strong></summary>

Technology and WAF fingerprinting

WAF learning, request calibration, and adapti recovery

HTTP and headless-browser application crawling for traditional and client-rendered applications

Ja and AST-assisted endpoint analysis, including lazy-loaded application chunks

Hidden GET, POST, JSON, XML, multipart, GraphQL, WebSocket, header, cookie, and path-identifier parameter discovery

Directory, file, backup, and administrati fuzzing, including directory-index detection and parent-directory inference from static assets

403 Forbidden bypass testing with header and path transformations

Reflection-context analysis

DNS, HTTP, and SMTP OAST callback collection and correlation

Interactive HTML, JSON, Markdown, CSV, and SARIF report generation

</details>

<details>
<summary><strong>2. Injection and code-execution testing</strong></summary>

SQL injection: error-based, union, boolean, time-based, and OAST-assisted checks

Reflected, DOM, stored-candidate, and blind XSS

Command injection and remote-code-execution signals

Ser Request Forgery (SSRF)

XML External Entity (XXE) injection

Local File Inclusion (LFI) and path tra

Ser and Client-Side Template Injection (SSTI/CSTI)

NoSQL, LDAP, and XPath injection

Insecure deserialization

CRLF injection and HTTP response splitting

Ser Ja injection

React Ser RCE checks

PDF generation injection and SSRF

AI/LLM prompt-injection checks

Second-order and delayed injection workflows

</details>

<details>
<summary><strong>3. Authentication, authorization, and session security</strong></summary>

Insecure Direct Object References and Broken Object Le (IDOR/BOLA)

Broken Function Le (BFLA)

Route-authentication bypass

Broken and improper authentication checks

JSON Web Token (JWT) security

OAuth and OpenID Connect flow security

Cross-Site Request Forgery (CSRF)

Rate-limit and bypass

Account-recovery weaknesses and account enumeration

Multi-tenant isolation checks

Cookie and session security

Session lifecycle and termination checks

</details>

<details>
<summary><strong>4. Client-side and web-protocol security</strong></summary>

Cross-Origin Resource Sharing (CORS) misconfiguration

Open redirects

Ja prototype pollution

HTTP Parameter Pollution (HPP)

Host-header injection and poisoning

HTTP request smuggling (CL.TE and TE.CL)

Web cache poisoning, cache deception, and Cache-Poisoned Denial of Service (CPDoS)

WebSocket security and Cross-Site WebSocket Hijacking (CSWSH)

GraphQL security and introspection exposure

gRPC and gRPC-Web protocol security

Re path confusion

JSONP callback abuse and XSSI exposure

</details>

<details>
<summary><strong>5. Information disclosure and exposed resources</strong></summary>

Exposed Git repositories and reco source artifacts

Backup and archi

Sensiti and configuration, including en and application config files

Source-code disclosure

Secrets, API keys, tokens, private keys, and sensiti exposure

Swagger and OpenAPI documentation exposure

Debug and administrati

Spring Boot Actuator, Spring Cloud Config, and Jolokia exposure

DevOps and CI/CD pipeline exposure

Cloud storage, cloud-native API, and subdomain-takeo

Cloud security posture obser

WordPress exposure scanning

Nginx alias tra

Next.js middleware bypass

Framework debug and de exposure for supported stacks

IIS shortname confusion

Firebase Realtime Database and Storage exposure

Enterprise SaaS exposure checks for supported services

</details>

<details>
<summary><strong>6. Business logic and security posture</strong></summary>

Race conditions and concurrency flaws

Business-logic test workflows

Arbitrary file-upload checks

Dangerous HTTP methods

API and hidden API endpoints

Mass assignment

Webhook signature and security

Parser differential analysis

Security headers and TLS/SSL configuration

third-party components and known-C

Ja source analysis

</details>

Scope and scan limits

Set a total request budget and maximum duration:

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

Full Scan has no implicit post-discovery module budget. When an operator explicitly sets a positi, AKCA distributes it across modules, URLs, and parameters, and unused allocations mo to later work. A positive --request-budget takes precedence over --requests-per-target.

| Option | Purpose |
| --- | --- |
| --request-budget 5000 | Cap total requests, including discovery, retries, and redirects |
| --requests-per-target 200 | Optionally derive a bounded module budget from discovered URL/method combinations; default 0 is unlimited |
| --crawler-budget 1500 | Limit discovery requests |
| --time-budget 30m | Limit scan duration |
| --rate-limit 5 | Limit requests per second |
| --concurrency 4 | Limit concurrent workers |

By default, crawl traffic is capped at 1,500 requests and 1,000 pages. The discovered endpoint in remains unlimited so distinct HTTP method such as GET and POST and hidden routes are retained. The module scan has no request quota. Budget interruptions are reported as incomplete co. Interrupted targets are not automatically resumed when later work returns unused budget. No budget setting guarantees detection of every .

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 co and e 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 from a single response difference.

A comprehensive run may take longer because AKCA:

Maintains a browser session for client-rendered routes and inspects Ja, including lazily loaded application chunks.

Replays promising results with controls before promoting them to findings, reducing false positi 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 obser windows instead of treating speed as the only success metric.

Scan duration also depends on application size, response latency, authentication flows, defensi, 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 in starts a new scan.

HTML reports are self-contained and include the AKCA logo, risk and se summaries, statistics, structured finding details, and expandable HTTP e. 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. Passi findings retain an excerpt around the match.

Depending on the module, findings include:

Recorded HTTP requests and responses.

Payloads and cURL reproduction commands.

Confidence, obser, and proof-policy status.

CWE and OWASP mappings.

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

When the scanner stored a complete raw transaction, the report preserves it exactly. Older or structured-only e is rendered in a con 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 ne the stored portion as the una complete response.

Replay a stored finding:

Reports mask recognized credentials by default. Raw stored e 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, exact hostnames may be configured separately:

This permits only GET/HEAD script, stylesheet, image, font and media requests to those hosts, stripping credential and custom headers. Successful in-scope HTML may also teach the browser up to 32 exact passi hosts found in resource tags or CSP; redirects, API calls and acti probes are ne this way. It does not add those hosts to the active scan scope. Blocked browser dependencies produce co events.

Discovered URLs are retained even when they cannot be . 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 capabilities.

Unconfigured rate-limit checks produce obser, not 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 e alone as proof. New SQL errors in 400/422 responses must pass the replay and control path.

What's new in v0.2.7

Generate scan IDs automatically so every in and future GUI-created scan has a stable unique identity.

Allow independent scan processes to share the WAL-backed SQLite store without a machine-wide scan lock.

Remove the implicit per-URL Full Scan module budget so SQL injection and similar finite checks are not silently cut short.

Keep explicit operator budgets a, while moving unused request allocation forward across later module work.

Bound hidden-parameter discovery around realistic Arjun-style probing instead of treating every obser as a useful parameter candidate.

Reject HTTP 200 WAF block pages as Ser Ja timing e and require matched, statistically consistent delay controls.

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ü 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 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, , 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 ; knowing that this project inspired a helpful act would mean a great deal to me.

De

Build from source:

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

Run checks from the engine directory:

The operational benchmark measures its obser. The complete-corpus gate additionally requires and safe/control fixtures for every runnable module and fails if a required browser, OAST, or authentication capability is skipped. For implementation details and limitations, read the architecture guide and audit.

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

Important note:

I am constantly running li and pushing updates whenever I encounter false positives or missed .
There are a lot of modules, and frankly, I ne you to like the tool this much—which motivates me even more and drives me to work harder.
Thank you for your support.

License

Apache License 2.0 · Copyright 2026 AKHA Security contributors.

项目信息

开发语言：Go

Star 数：224

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕AKCA Advanced Web Security Scanner展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。