Deep Auth DAST: Test What Changes After Login—and Across Authorization Boundaries
Many of the most important WordPress workflows are invisible to an anonymous scanner. Aegisify Deep Auth DAST uses customer-authorized authentication context to discover protected application paths, compare behavior across approved user contexts, review session and authorization boundaries, validate live security behavior, and document what could—and could not—be tested.
Auth
What Is Deep Auth DAST?
Deep Auth DAST is the default advanced profile in the current shortcode and is designed for runtime security questions that depend on login state, role, session, or protected routes.
The assessment establishes an unauthenticated baseline, then uses valid customer-approved authentication context to discover and evaluate application behavior that is not visible to a guest. Where more than one valid context is available, Aegisify can compare route visibility and authorization behavior across roles or privilege levels. It also evaluates session-related signals, protected API behavior, workflow controls, client-side exposure, and other dynamic evidence supported by the discovered surface.
This is particularly useful for membership sites, ecommerce administration, editorial workflows, customer portals, account dashboards, custom WordPress applications, and any site where the most sensitive business functions occur after login.
How Deep Auth DAST Builds Role-Aware Runtime Evidence
Open each stage. The workflow is intentionally described without revealing reusable authentication recipes, credentials, internal routes, probe values, or exploit mechanics.
Click a stage to expand
01Verify Targetapproved site
02Guest Baselinepublic routes
03Load Auth Contextcustomer-approved
04Discover Protected Surfaceroutes + forms + APIs
05Compare Boundariesrole + object + route
06Validate Securitysession + workflow + DAST
07Report & Verifyevidence + retest
What Deep Auth Needs Before It Can Test Protected Behavior
What Deep Auth DAST Reviews
The current profile spans nine major DAST families. Availability still depends on what the site exposes and which prerequisites are satisfied.
Login, Session State, Cookies, and Logout
Reviews whether authenticated state is created, maintained, and ended in a way consistent with the intended boundary. It also evaluates browser-observable cookie and session signals that may affect account security.
Role, Route, Object, and Privilege Boundaries
Compares approved contexts to identify routes or operations that appear more accessible than expected, including object- and privilege-oriented authorization candidates that deserve review.
Stateful Requests and Security Controls
Evaluates security-relevant behavior around state-changing workflows, request validation, anti-forgery/nonce posture, and other application controls where the test can be performed safely.
Protected REST and API Behavior
Reviews APIs reachable within authenticated context for authentication expectations, object access, response exposure, contract inconsistencies, parameter-handling risk, and related OWASP API-oriented conditions.
Controlled Input Validation
Applies bounded canary-style checks for supported injection categories and uses response differences and other evidence to identify candidate unsafe input handling without documenting destructive payloads.
DOM, Scripts, Storage, and Source Maps
Reviews client-side route references, script trust relationships, DOM-related risk signals, source-map exposure, and browser storage/token indicators visible within the authorized application state.
Headers, Caching, Cookies, and Artifacts
Correlates runtime hardening evidence such as security headers, sensitive caching behavior, cookie properties, exposed artifacts, and other externally observable conditions.
Protected File Workflows
Where upload or file-handling functionality is discovered and in scope, the scanner reviews relevant authorization and handling behavior using bounded validation.
Authenticated Attack-Surface Graph
Builds route, form, API, role, and relationship inventories so findings can be interpreted against the actual surface observed in guest and authenticated states.
Why Comparing Authenticated Contexts Is More Useful Than a Single Logged-In Crawl
A single authenticated session tells you what one account can see. It does not, by itself, show whether another role can reach the same route, whether an object boundary behaves differently, or whether a more privileged operation is adequately separated from a less privileged context. Deep Auth therefore treats authentication context as part of the evidence model rather than simply a way to bypass the login page.
What Appears After Login?
Aegisify can compare guest and authenticated route visibility and, where multiple valid contexts exist, show how the reachable surface changes between those contexts. This helps expose hidden administrative, account, API, and workflow paths that do not exist in a public crawl.
What Does the Application Actually Allow?
Discovery is followed by authorization-oriented validation. Findings are based on observed behavior and evidence, while ambiguous or unsupported cases can remain candidates for manual review instead of being promoted to certainty.
How Deep Auth Uses the Aegisify Agent
The Agent does not replace dynamic testing. It adds local WordPress context that helps the SaaS understand the environment it is testing.
The Agent’s optional telemetry policy is separate from the core scan connection. Telemetry sharing starts disabled in the supplied Agent and can be enabled by category for metadata such as software versions, integrity, administrative inventory, cron, backup/restore, drift, privileged configuration states, and optional activity/log access.
What the Agent Can Observe Locally
The current Agent defines local activity sensors across users, settings, plugins, themes, core, files, content, taxonomy, comments, media, menus, options, and Aegisify Audit activity. Most are enabled by default. Four high-volume option-change sensors are disabled by default to reduce noisy event collection.
These sensors can provide operational context over time, but local sensor collection is not the same as SaaS telemetry authorization. Optional WordPress activity-log retrieval requires the corresponding telemetry permission, and the Agent enforces the master telemetry access control before that category becomes available.
Optional Rendered Discovery Expands What a Server-Only Crawl Can See
Modern WordPress applications can reveal routes only after JavaScript runs, a user clicks through an interface, a form changes state, or an authenticated page renders client-side content. The advanced engine therefore supports an optional browser-assist path for rendered route discovery, DOM coverage, click-path expansion, form inventory, and post-login state mapping.
The supplied implementation treats this browser worker as an inventory and validation component. It is not designed as a remote exploit-delivery channel, and the plugin does not need to send exploit payload instructions to the browser worker.
How Deep Auth Starts—and Where Each Part Runs
Advanced Dynamic Run
An authenticated customer launches Deep Auth from the advanced shortcode against a verified domain. The selected coverage is recorded in the run plan before execution.
Daily, Weekly, or Monthly
The same profile can be saved as a recurring advanced scan so authenticated runtime review can become part of an operating cadence rather than a one-time assessment.
SaaS-Orchestrated Job
Longer discovery and validation work runs through the background queue. SaaS coordinates the live-site tests while Agent work runs locally and optional browser-assisted discovery runs through its configured worker.
Focused Retest or Full Rerun
After remediation, supported findings can be retested in context, or the complete Deep Auth profile can be rerun to verify the wider authenticated attack surface and regression state.
What You See After the Scan
Who Can See What
Visualizes differences in observed route and surface visibility between guest and approved authenticated contexts.
Authorization-Oriented View
Organizes route/access evidence by context so teams can identify unexpected privilege relationships and prioritize manual review.
Coverage by Session Context
Records which authentication contexts were available to the assessment and how they contributed to coverage.
Expected vs. Observed Behavior
Normalizes route and API characteristics so authentication, method, and response behavior can be reviewed consistently.
Evidence Confidence
Separates stronger verified observations from candidates, suppressed results, and not-tested conditions instead of treating every scanner signal as equivalent.
Repeatable Verification
Preserves enough normalized context for later scans and focused retests to determine whether the behavior changed after remediation.
OWASP Web Top 10 mappingsOWASP API Top 10 2023OWASP WSTGCWE
From Authenticated Finding to Verified Fix
Establish Authorized Context
Use only customer-approved accounts or session material on a verified target. Confirm that the role and application state match the security question you want to test.
Run the Deep Auth Profile
Allow Aegisify to build the guest baseline, discover authenticated routes, gather optional Agent/browser evidence, and execute the supported role-aware dynamic checks in the background.
Review Findings and Coverage Together
Prioritize confirmed evidence, but also review the not-tested/degraded view. A missing role context or unreachable feature can be as important to audit quality as the findings themselves.
Remediate and Retest
Apply changes through normal development/change control, then use a supported focused retest for the specific finding or rerun Deep Auth to validate the broader authenticated attack surface.
Common Questions
Why not just scan the site while logged in once?
A single logged-in crawl expands visibility but does not necessarily show how access changes across roles or how a protected operation behaves under a different context. Deep Auth is designed to compare context and authorization behavior, not merely to bypass the login screen.
What happens if only one valid authentication context is available?
Authenticated route discovery and single-context checks may still contribute evidence, but role-comparison coverage requires multiple valid contexts. The report should reflect that limitation rather than imply multi-role coverage occurred.
Does the Agent hold the entire DAST engine?
No. The dynamic scan is SaaS-orchestrated. The Agent contributes authorized local WordPress context such as inventory, permission/context evidence, and correlation data. The live behavior is still evaluated against the running verified application.
Does Deep Auth replace a code review?
No. Deep Auth observes runtime behavior. Use SAST Static Code Analysis when you need code-level review and Vulnerability Scan for broad software/vulnerability posture.
Can Deep Auth guarantee that access control is secure?
No. It tests the reachable and authorized scope with the contexts and evidence available at the time of assessment. It can identify and prioritize risky behavior, but no finite DAST run can prove the absence of every authorization flaw.