Hackaiz

Methodology

How Hackaiz proves a flaw — and what it never does

Short answer

Hackaiz only reports a flaw when it is proven: the request is replayed, the response is kept, and the result is classed Danger, To fix or To watch. Every check first requires proof that the system is yours, and nothing is ever changed without your explicit approval.

By the Hackaiz team · HACKTUALIZ Inc. · Updated

Start my first scan

1. Authorization first

No check starts without ownership proof: a DNS record or HTTPS file for a site, a verified GitHub App for a repository, a read-only connection for a database. Authorization is timestamped, revocable and re-verified on every analysis.

2. Read-only by default

Checks use GET, HEAD and OPTIONS requests, paced and volume-limited. Database audits read the catalog and access rules, never your data. The real browser is confined to the proven domain.

3. Evidence for every flaw

A flaw is only reported when replayed: the request and response (or the exact code location) are kept as evidence, with secrets masked. An uncertain result is marked inconclusive — never presented as safe or as dangerous.

4. Fixes prepared, never imposed

Hackaiz prepares the fix: a GitHub pull request you review and merge yourself, or a remediation guide for what cannot be automated. No automatic merge, no direct modification of your sites or databases.

5. Re-verification and monitoring

After a fix, a new check confirms the evidence is gone; for code, your repository tests and deployment proof are taken into account. With your approval, monitoring re-runs the analysis when something changes.

What Hackaiz never does

  • No destructive testing: no denial of service, no deleting or modifying data.
  • No analysis without ownership proof and recorded authorization.
  • No invented or inflated flaws: a clean result is reported as such.
  • No automatic merge, no writes without your explicit approval.
  • No identifiable customer data in public statistics: only anonymized aggregates.