Notifications
Clear all
Topic starter
18/08/2026 2:40 pm
TL;DR: Traditional scanners can verify that endpoints exist and authenticate correctly, but they still miss business-logic failures where the wrong actor can perform a valid action, according to Ethiack’s analysis of Hackian. The practical shift is toward identity-aware testing that evaluates role boundaries, parameter reuse, and cross-user access decisions, not just technical vulnerability signatures.
NHIMG editorial — based on content published by Ethiack: Hackian and the Ghosts in Your Business Logic
Questions worth separating out
Q: What breaks when identity controls are not tied to business value?
A: When identity controls are not tied to business value, they are easier to delay, underfund, or scope too narrowly.
Q: Why do multi-identity workflows expose gaps that single-user testing misses?
A: Because many authorisation bugs only appear when two sessions interact with the same object, token, or parameter.
Q: How do you know if application authorisation is actually working?
A: Look for consistent denial of actions, objects, and metadata across different roles and sessions.
Practitioner guidance
- Test critical workflows with multiple identities Run the same business process as guest, standard user, and privileged user, then compare object visibility, action outcomes, and returned metadata.
- Add semantic assertions to API testing Write tests that fail when an endpoint returns sensitive state to a session that is authenticated but not authorised for that object.
- Gate releases on access-control replay tests Before deployment, replay tokens, object IDs, and workflow parameters across identities to confirm that one user cannot inherit another user’s privilege or data view.
What's in the full article
Ethiack's full article covers the operational detail this post intentionally leaves for the source:
- Workflow-level examples of how Hackian maps user journeys before testing control boundaries
- Endpoint-by-endpoint detail on how branch metadata and infrastructure settings were surfaced
- The report’s description of how multiple identities were coordinated to probe access rules
- Timing and disclosure context around the SonarQube and n8n findings
👉 Read Ethiack's analysis of Hackian's autonomous business logic testing →
Business logic flaws and multi-identity testing: what teams miss?
Explore further
18/08/2026 3:24 pm
Business logic flaws are an authorisation problem, not just a testing gap. When an application returns the right technical response but to the wrong identity, the core failure is governance of access decisions. That is why application security and IAM teams need shared ownership of workflow validation, not siloed responsibility. The practitioner conclusion is simple: test authorisation as a business rule, not as a code pattern.
A question worth separating out:
Q: Who is accountable when a workflow exposes data to the wrong user?
A: Accountability usually sits across application engineering, security testing, and IAM governance. Engineering owns the workflow logic, security owns validation and detection, and identity teams own role design and entitlement scope. When exposure happens, teams should trace whether the failure was in policy definition, implementation, or verification, then close the loop in release governance.
👉 Read our full editorial: Autonomous business logic testing exposes access-control gaps in apps
