WordPress Dynamic Security Scan: Test the Running Application, Authenticated Paths, and API Attack Surface
Aegisify Advanced Dynamic Security Scan examines the behavior of an authorized, verified WordPress site while it is running, then combines dynamic discovery, safe active validation, authenticated context, API intelligence, optional browser-assisted coverage, Agent evidence, and repeatable reporting into one workflow.
Aegisify keeps those questions separate so WordPress teams can combine vulnerability intelligence, SAST, and DAST without treating one scan type as a substitute for another.
DAST
What Is Aegisify Advanced Dynamic Security Scan?
It is a profile-driven DAST workflow for security teams that need more than a public unauthenticated crawl.
Dynamic Application Security Testing, or DAST, evaluates a running web application from the outside by discovering reachable surfaces and observing how the live application responds to controlled security tests. Aegisify’s advanced family extends that model with WordPress-aware discovery, authenticated context when authorized credentials or session material are supplied, API inventory, browser-side evidence, optional Agent context, and a structured evidence model that records not only what was found but also what was tested, skipped, suppressed, or unavailable.
Aegisify provides three advanced profiles with different priorities: Deep Auth DAST, API DAST, and API DAST and Compliance. The broader workflow also supports saved schedules, scan history, reporting, comparison between recent completed scans, finding workflow state, and supported focused retesting.
How an Advanced Dynamic Scan Moves From Scope to Verified Action
Open each stage to see the public-safe workflow. Exact scanner payloads, internal endpoints, sensitive thresholds, and exploit logic are intentionally not reproduced.
Click a stage to expand
01Verify Scopeauthorized domain
02Select ProfileAuth, API, Compliance
03Build Plancoverage + prerequisites
04Discover Surfaceweb + API + browser
05Validate Behaviorbounded active tests
06Correlate Riskevidence + context
07Act & Retestremediate + compare
Choose the Dynamic View That Matches the Security Question
All three profiles share the same orchestration and reporting model, but each emphasizes different evidence.
Deep Auth DAST
Prioritizes authenticated route inventory, authorized session context, multi-role visibility, authorization boundaries, session behavior, protected application paths, and role-aware replay. Use it when the important security question begins after login.
API DAST
Prioritizes REST namespaces, browser- and JavaScript-exposed routes, documented and discovered API contracts, OpenAPI/GraphQL evidence when present, OWASP API-aligned test families, and API inventory state.
API DAST and Compliance
Runs the API-focused dynamic workflow and adds Agent-assisted application-security and database-posture control checks mapped to supported DISA SRG and NIST references. It provides evidence for review; it is not a compliance certification.
What the Advanced DAST Family Reviews
The exact set depends on the selected profile and available prerequisites. The public categories below describe the current rule-family model without disclosing probe mechanics.
Unsafe Input Handling
Looks for response and behavior patterns associated with injection-style weaknesses, including browser, data, request-routing, and path-handling conditions. Validation is bounded and evidence-driven rather than destructive.
Login and Session Boundaries
Reviews login-related behavior, cookies, session state, logout behavior, token/session handling signals, and whether authenticated paths behave consistently with the expected security boundary.
Authorization and Role Boundaries
Examines whether routes, objects, and privileged operations appear to enforce the expected access boundary across guest and authorized user contexts.
REST, OpenAPI, GraphQL, and Contract Risk
Builds an API inventory and reviews authentication expectations, object access, response exposure, schema/contract consistency, resource-use posture, and other API security conditions supported by the profile.
DOM and JavaScript Exposure
Reviews front-end route references, script relationships, source-map exposure, browser storage/token signals, third-party script trust indicators, and browser-observable conditions that server-only discovery can miss.
Headers, Cookies, Artifacts, and Public Signals
Checks externally observable security posture such as headers, caching behavior, cookie properties, installation artifacts, protocol-related signals, and other hardening evidence relevant to the running application.
Stateful and Write-Aware Behavior
Where the profile and scope safely allow it, Aegisify evaluates security controls around stateful operations, request validation, workflow boundaries, and write-aware application behavior without publishing destructive test recipes.
File Workflow Boundaries
Reviews discovered upload and file-handling surfaces for security-relevant behavior and authorization posture when those surfaces are in scope and can be evaluated safely.
Attack-Surface Truth
Builds route, form, API, role, browser, and relationship inventories so teams can see what was discovered, which paths were eligible for testing, and where evidence is incomplete.
Advanced DAST Does Not Replace Vulnerability Scan or SAST
The three assessment families answer different questions and are strongest when used together.
Vulnerability Scan
Reviews WordPress software, versions, known vulnerability relationships, defensive posture, dependencies where supported, hardening, exposure, and operational evidence. It answers: what known or observable risk exists in this environment?
SAST Static Code Analysis
Uses Agent-assisted local static analysis to review supported WordPress code and security-relevant implementation patterns without treating full source-code bodies as the normal SaaS result payload. It answers: what risky patterns exist inside the code?
Advanced Dynamic Security Scan
Exercises the live application within verified scope and observes actual runtime behavior, authenticated differences, API exposure, browser-side surface, and dynamic control evidence. It answers: what does the running application expose or allow?
Where the Work Happens
Advanced DAST is coordinated by Aegisify SaaS, but the evidence can come from several controlled locations.
Local Activity Sensors and SaaS Telemetry Access Are Separate Controls
The Agent can collect WordPress security context locally while the administrator separately controls which supported telemetry categories SaaS may access.
WordPress Activity Evidence
The supplied Agent defines activity sensors across user events, settings, plugins, themes, WordPress core, files, posts, taxonomy, comments, media, menus, options, and Aegisify Audit activity. Most sensors are enabled by default, while four high-volume option-change sensors are disabled by default to reduce noise.
Sensors determine what supported activity is recorded locally. They do not automatically grant SaaS access to every recorded activity event.
Administrator-Controlled Metadata Sharing
Telemetry sharing begins disabled in the supplied Agent. Administrators can enable the master control and then separately authorize supported categories such as software-version metadata, integrity hashes, administrative inventory, cron/event inventory, backup/restore telemetry, snapshot differences, file-drift history, privileged configuration states, and optional log/activity retrieval.
The Agent’s declared privacy mode is metadata-focused and excludes site content and sensitive values from routine telemetry categories.
What Is Enabled by Default—and What Requires Administrator Action?
Only public-safe defaults are documented here. Sensitive limits, tokens, scanner internals, and exact detector settings remain inside the product.
Purpose-Built Coverage
Each advanced profile selects the modules and rule packs appropriate to its purpose. Any allowed module changes are saved into the scan plan so reporting can describe what actually ran rather than assuming full coverage.
Test What Can Be Supported
Authenticated review requires usable administrator-authorized authentication context. Role comparison requires multiple valid contexts. OpenAPI and GraphQL checks depend on in-scope evidence revealing those technologies. Agent-specific evidence requires a connected compatible Agent. Missing prerequisites are surfaced as skipped, degraded, not observable, or otherwise not tested rather than silently inferred.
Manual Runs, Scheduled Runs, and Focused Retesting
Manual Advanced Dynamic Run
An authenticated user selects a verified target, chooses one of the three advanced profiles, reviews the available profile coverage, and launches the scan. Longer work is placed into the background so the browser does not need to stay open while the assessment completes.
Recurring Schedule
Aegisify supports saved recurring advanced scans on daily, weekly, or monthly cadences. The scheduled job reuses the approved profile and target context so organizations can turn dynamic testing into a repeatable control rather than a one-time event.
Focused Finding Retest
Supported dynamic findings can be retested after remediation. The retest workflow is designed to verify the relevant finding context without treating the original result as permanent truth or requiring users to manually reconstruct the complete report.
Full Profile Rerun and Comparison
For broader assurance, rerun the complete profile and compare recent completed assessments. This captures both the resolved issue and any new exposure introduced by application, plugin, theme, API, authentication, or configuration changes.
The Result Is More Than a Severity List
Aegisify organizes results so teams can understand both risk and coverage quality.
Routes, Forms, APIs, Roles, and Relationships
Inventory views help explain what the assessment discovered and how pages, API routes, authentication contexts, browser assets, and application relationships contribute to the tested attack surface.
Tested, Skipped, Suppressed, and Not Tested
Aegisify records coverage state and skip/degradation reasons so a clean result is not confused with a check that could not run because credentials, Agent capability, browser coverage, or application evidence was unavailable.
Evidence, State, and Retest
Findings carry normalized severity and evidence, can move through an operational state workflow, and can be revisited through full rescans or supported focused verification after remediation.
Role Visibility and Access Matrix
Deep Auth results can include role-oriented visibility, authorization boundary review, route contracts, and authentication-context inventory that help explain where behavior differs across approved contexts.
API Inventory and Contract Evidence
API profiles expose route inventory, discovered-versus-documented state, contract evidence, authentication expectations, and related security findings in a form designed for remediation planning.
Latest vs. Previous
Recent completed assessments can be compared so teams can see whether risk moved in the expected direction, whether coverage changed, and whether remediation introduced or removed observable findings.
OWASP Web mappingsOWASP API Top 10 2023OWASP WSTG referencesCWE mappings
Common Questions About Aegisify Advanced DAST
What is the difference between Advanced Dynamic Scan and Vulnerability Scan?
Vulnerability Scan is the defensive/static-oriented assessment for WordPress software, known vulnerability relationships, dependency evidence where supported, hardening, exposure, and operational posture. Advanced Dynamic Scan tests the behavior of the running application. They complement each other.
Is SAST included inside Advanced Dynamic Security Scan?
No. SAST Static Code Analysis is a separate Agent-assisted static assessment. The advanced dynamic profile can use Agent context, but that does not turn the DAST job into a source-code scan.
Does every Deep Auth test run if credentials are missing?
No. Authenticated and role-aware coverage depends on valid administrator-authorized authentication context. The reporting model is designed to show incomplete or skipped coverage instead of implying that protected routes were tested anonymously.
Does browser-assisted discovery deliver exploits?
The supplied browser-assist integration is designed for inventory and validation such as rendered-route discovery, DOM coverage, click-path expansion, form inventory, and post-login state mapping. The implementation specifically separates that inventory function from exploit delivery.
Does turning on Agent sensors automatically share everything with SaaS?
No. Activity sensors control supported local event collection. Telemetry access is a separate administrator-controlled authorization layer and begins disabled in the supplied Agent.
Can this scan prove that a site is secure or compliant?
No. Dynamic testing reduces uncertainty by collecting evidence about the tested scope at a point in time. Results depend on reachable functionality, credentials, configuration, available evidence, and test coverage. Compliance mapping and baseline checks support review but do not provide certification or a guarantee of security.