Enterprise DAST for WordPress Applications and Commerce: Deeper Live Security Validation
Enterprise DAST: App & Commerce is the broader default Dynamic Security Scan profile in Aegisify Audit. It combines the public DAST baseline with deeper route discovery, REST and API analysis, OpenAPI and GraphQL detection, browser/client-side review, access-control testing, attack-surface graphing, and Commerce checkout, payment, webhook, cart, account, order, and compatibility intelligence when those surfaces are detected.
Enterprise DAST is designed for sites where APIs, client-side code, authentication, business workflows, ecommerce, and WordPress internals all influence the real attack surface.
How Enterprise DAST Builds a Broader Application Security View
Open each stage for the public-safe workflow. Internal scanner payloads, signatures, authentication mechanics, and evasion-sensitive limits are intentionally excluded.
Click a stage to expand
01Scopeexample.com
02DiscoverWeb + API + assets
03EnrichAgent + Commerce context
04TestSafe active validation
05CorrelateEvidence + coverage truth
06VerifyRemediate + retest
The Default Dynamic Profile for WordPress Applications and Commerce
The current Enterprise DAST profile merges the former Standard DAST baseline with deeper application, API-authorization, browser, and Commerce coverage.
Enterprise DAST is the default profile in the current Dynamic Security Scan family. It is intended for WordPress sites that expose more than static pages: membership applications, customer portals, API-driven front ends, WooCommerce stores, custom forms, authenticated workflows, and other business-critical WordPress applications.
The profile activates Public Exposure, Normal Crawl, lightweight Browser Crawl, REST Discovery, OpenAPI Discovery, GraphQL Discovery, Session Tests, Authorization Tests, Front-End DOM Checks, Active Probes, and Attack Surface Graph capabilities. These capabilities are backed by rule families for web security, deeper web behavior, API security, API authorization, front-end analysis, and session/authentication review.
Web, API, Browser, Access-Control, Discovery, and Workflow Testing in One Profile
Enterprise DAST includes the Quick DAST baseline and adds a substantially larger set of dynamic security questions. The categories below reflect the implemented coverage without publishing exploitable test mechanics.
Response Hardening and Sensitive Exposure
Reviews security headers, frame controls, content-security posture, cookie hardening, sensitive caching behavior, and exposed artifacts that can weaken the externally visible application baseline.
Cookie, Session, Logout, Timeout, and Admin Boundaries
Evaluates browser-session protections, unauthenticated administrative exposure, fixation indicators, logout invalidation, and session timeout posture.
Input Handling Across Common Dynamic Weakness Classes
Safely reviews redirect handling, reflected client-side injection signals, relational and non-relational database injection indicators, server-side request behavior, and path traversal-style input risk.
Request State, Stored Workflow Candidates, and Parameter Semantics
Reviews CSRF/nonce posture, stateful workflows where stored client-side injection may be relevant, and parameter-pollution behavior that can change how back-end logic interprets a request.
Object, Function, and Privilege Boundaries
Identifies IDOR/BOLA candidates, mass-assignment indicators, and privilege-escalation candidate routes where authorization or property boundaries may not match the intended user, object, or function boundary.
File Upload Candidate Workflows
Discovers upload-related surfaces and flags candidates for controlled review of authorization, path, type, and processing posture without publishing upload-bypass mechanics.
Authentication, Methods, Data, Schema, Inventory, and Resource Controls
Reviews API authentication requirements, unauthenticated methods, excessive data exposure, schema mismatch, token-in-URL conditions, GraphQL introspection exposure, pagination/rate-limit posture, GraphQL depth/complexity controls, and improper inventory visibility.
DOM Signals, Source Maps, Client Tokens, and Third-Party Scripts
Examines fetched front-end assets for DOM/client-side weakness indicators, source-map exposure, secret or token-like signals, and third-party script relationships that expand browser-side risk.
API Inventory, Attack-Surface Graph, and Route Contracts
Covers OpenAPI discovery, route-contract harvesting, and attack-surface graph coverage so discovered APIs, parameters, authentication expectations, and cross-surface relationships can be preserved for coverage truth and later replay.
Checkout, Store API, Payments, Webhooks, Orders, and Compatibility
When Commerce is active, Aegisify adds checkout-model detection, Store API and REST route discovery, payment and webhook classification, cart/coupon/account/order exposure review, safe checkout replay, payment asset review, workflow replay, and HPOS, Action Scheduler, and template-override context.
Enterprise DAST Builds the Test Surface Before It Tries to Judge It
A security test is only as useful as the surface it actually discovered. Enterprise DAST therefore treats discovery and inventory as first-class evidence.
The normal crawl provides standard HTTP link and path discovery. Browser Crawl in this release adds lightweight front-end route and DOM heuristics, source-map and asset discovery, but it is not a full AJAX-rendered browser spider. That distinction is important when a site depends heavily on client-side navigation that does not appear in fetched HTML or linked assets.
OpenAPI coverage activates only when an in-scope definition or strong discovery signal is present. GraphQL coverage activates only when a GraphQL endpoint can be identified. Those conditional prerequisites are reported as coverage truth rather than being silently marked as passed.
Four Agent Evidence Stages Add an Inside-Out View to the Outside-In DAST
The Enterprise profile uses the connected Agent to obtain authorized metadata that public requests alone cannot reliably provide.
WordPress Hardening Context
The Agent evaluates a small set of internal WordPress hardening conditions such as version exposure, XML-RPC state, debug posture, file-edit/modification posture, admin SSL enforcement, exposed readme artifacts, and detected WordPress version. This helps explain whether an external observation reflects WordPress configuration or only edge behavior.
Local WordPress Inventory
The Agent builds metadata inventory for WordPress core, active/inactive plugins and themes, must-use plugins, roles, runtime posture, database configuration/privilege posture, Site Health, REST routes, public REST exposure, registered admin-ajax actions, and supported dependency manifest inventory. In this Enterprise DAST stage, dependency-audit commands themselves are intentionally not run; the Agent supplies the inventory context.
Commerce Posture When WooCommerce Is Active
The Agent collects privacy-preserving Commerce metadata about platform/update posture, checkout model and registration settings, enabled payment gateway identifiers and configuration posture, webhook counts and destination posture, REST API key counts and permission categories, Store API / REST surface, HPOS, Action Scheduler, template overrides, log-exposure indicators, and privileged-user counts.
Aegisify Suite Correlation
The Agent can identify whether Shield-, WAF-, or Spam-related Aegisify components appear active so the SaaS result can correlate dynamic observations with the presence of local defensive controls. Presence is contextual evidence; it is not proof that a control blocked every attack class.
Commerce Coverage Goes Beyond “Is WooCommerce Installed?”
When WooCommerce is active, Enterprise DAST combines public workflow discovery with local metadata so checkout and payment risk can be interpreted in context.
Identifies whether checkout is classic, block-based, mixed, or otherwise uncertain so later review understands which request and client-side behavior matters.
Inventories Store API and Commerce REST surfaces and reviews how authentication, callbacks, and public route behavior align with expected access.
Records enabled gateway identifiers and high-level test/debug/tokenization posture without collecting gateway secrets or payment card values.
Reviews counts, active/inactive state, HTTPS posture, secret-presence indicators, and hashed destination-host context without transmitting webhook secrets.
Uses safe workflow replay logic to identify inconsistent validation, ownership, or state behavior across relevant Commerce actions.
Reviews HPOS state, Action Scheduler posture, and template override/version context because operational compatibility problems can create security and integrity gaps.
Enterprise Agent Enrichment Is Not the Same Thing as “Send Everything to SaaS”
The current Agent separates profile-specific scan results, WordPress activity sensors, and optional telemetry policy.
Activity sensors record supported WordPress events locally across users, settings, plugins, themes, core, files, content, taxonomy, comments, media, menus, options, and Audit activity. Most sensors are enabled by default, while four noisy option-change sensors are disabled by default.
Those sensors do not directly drive the base Enterprise DAST plan in this release. The profile does not require an activity-log fetch stage. Activity logging remains useful to the broader Aegisify Audit platform, but this page does not pretend that Enterprise DAST is reading every activity event.
Telemetry Access Control is a separate authorization policy. The master switch and all supported categories begin disabled. If an administrator enables them, the Agent can include approved metadata such as software versions, integrity hashes, administrative inventory, cron/event inventory, backup/restore telemetry, snapshot differences, file-drift history, privileged configuration state, or optional log-access permissions.
Agent inventory and Commerce scan stages return their own privacy-preserving scan evidence as part of the authorized Agent workflow. Optional telemetry can accompany those responses when approved, but disabling telemetry does not convert the Enterprise DAST profile into a failed external scan. It simply limits optional telemetry enrichment.
Enterprise DAST Is the Current Default and Runs as a Background Assessment
The broader profile is designed to continue independently of the browser because discovery and correlation can take longer than a quick public check.
Recurring schedules support daily, weekly, and monthly cadence, with new schedules defaulting to daily. Supported coverage modules can be adjusted by an authorized operator before a run, and the resulting module set is saved into the execution plan so later reporting reflects what was actually requested.
Enterprise DAST Records What It Could Test—and What It Could Not
Broad coverage is useful only if prerequisite failures are visible.
OpenAPI discovery requires a definition or strong in-scope discovery signal. GraphQL analysis requires an identifiable GraphQL endpoint. Commerce-specific testing requires Commerce detection. Agent-backed enrichment requires a working authorized Agent connection. If those prerequisites are absent, Aegisify limits that part of the assessment rather than representing missing evidence as a passing result.
The front-end crawler in this build is intentionally described as lightweight HTTP/DOM discovery rather than a fully rendered AJAX browser spider. This matters for highly dynamic applications whose routes appear only after complex client-side execution.
Enterprise DAST also remains distinct from deeper authenticated and API-focused advanced profiles that exist elsewhere in the Aegisify codebase. This public guide documents only the App & Commerce profile exposed by the standard Dynamic Security Scan family.
Enterprise DAST Is Built to Support the Full Security Decision Loop
Discovery depth matters, but the real operational value is being able to explain, remediate, and verify a finding.
Findings are normalized with category, severity, confidence, affected route or path, evidence context, remediation guidance, and false-positive guidance where implemented. The rule catalog also carries mappings to OWASP web/API categories, WSTG, and CWE for many checks. These mappings help organize technical evidence; they do not make the scan a formal certification.
The current DAST workflow supports focused retesting by creating a new verification job tied to the original finding, rule, affected path, and saved run plan. That approach gives the team fresh evidence while preserving the relationship to the original issue.
Common Questions About Enterprise DAST: App & Commerce
Is Enterprise DAST the default Dynamic Security Scan profile?
Yes. In the current implementation, Enterprise DAST: App & Commerce is the default profile. Quick DAST is the lighter alternative.
Does Enterprise DAST require WooCommerce?
No. The application, API, browser, access-control, discovery, and public DAST baseline applies to WordPress applications generally. Commerce-specific coverage activates when WooCommerce/Commerce surfaces are detected.
What does the Aegisify Audit Agent contribute?
The current Enterprise profile requests Agent-side hardening, local WordPress inventory, Commerce posture, and Aegisify-suite correlation. That adds internal metadata and configuration context that the external scanner cannot reliably infer.
Does the Enterprise Agent stage run dependency audits?
The local inventory can discover supported dependency manifests and package metadata, but the Enterprise DAST inventory stage currently requests that dependency-audit commands not be executed. Dependency vulnerability auditing belongs to other Audit workflows.
Does Enterprise DAST collect orders or payment data?
The supplied Agent code explicitly excludes orders, customer records, payment card values, gateway secrets, webhook secrets, REST API secrets, and raw log content from its Commerce intelligence payload. It returns metadata and security posture indicators instead.
Does Enterprise DAST run a full browser automation engine?
No. The current profile uses lightweight HTTP/DOM front-end discovery with asset and source-map analysis. It should not be described as a full AJAX-rendered browser spider.
What happens if the Agent is unavailable?
The external DAST stages can still run, but Aegisify records that Agent-backed internal coverage is limited. The result should be interpreted accordingly.