Home / Attacks & tests / Configuration and Deployment Management Testing
12 test cases
Configuration and Deployment Management Testing
Configuration testing examines the ground the application stands on rather than the code it runs: what the server exposes, what the deployment left behind, and which accounts and interfaces exist because a default created them. These are rarely defects in the application's own logic, and they are frequently the shortest route into it.
What an attacker is trying to achieve
The attacker is looking for the thing nobody owns — a backup file beside the live one, an administrative console on a secondary hostname, a registration flow that grants more than it should. These require no exploit development and no defect in the application, only that it was deployed faster than it was hardened.
Test cases
12 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-CONF-01 Application Configuration Management Weaknesses
Objective — Determine whether the application and the platform beneath it are deployed with development conveniences, debug facilities or permissive defaults still enabled in a production setting.
How it is tested — Request the framework and server facilities that ship enabled by default — debug consoles, profilers, health and metrics endpoints, configuration dumps — on every in-scope host, not only the primary one. Compare the security headers, error verbosity and directory behaviour of each host, since staging names frequently retain settings production has removed. Check whether configuration files, environment listings or dependency manifests are served as static content.
Prerequisites — The complete hostname list including non-production names; permission to request paths the interface never links.
Indicators — A debug or profiling endpoint responding; a configuration or environment dump served; directory listing enabled; a secondary host materially less hardened than the primary.
Coverage — WSTG-CONF-02V14.3.2CWE-1188
Depth — Hybrid Path probing is automated; knowing which defaults a given framework and version ships enabled is what makes the probe list worth running.
WEB-CONF-02 File Extension Handling
Objective — Determine whether the server's decision to execute, serve or refuse a file is driven by its actual type, and whether extensions the application never intended to publish are served as readable content.
How it is tested — Request known application files under alternative extensions and casings, and request extensions associated with source, configuration, archive and database content across the discovered directory structure. Where uploads exist, submit files whose extension, declared content type and actual content disagree, and determine which the server trusts when it decides whether to execute. Confirm whether appending an extra extension changes the handler that processes the file.
Prerequisites — The directory structure recovered during information gathering; upload functionality where present, exercised in a non-production environment.
Indicators — Source served as text rather than executed; an archive or database file retrievable; an uploaded file executed because the server trusted an extension rather than the content.
Coverage — WSTG-CONF-03V12.5.1V12.2.1CWE-434
Depth — Hybrid Extension enumeration is automated; the disagreement cases between extension, declared type and content are constructed by hand.
WEB-CONF-03 Old, Backup and Unreferenced Files
Objective — Determine whether files that are no longer part of the application remain retrievable — backups, editor artefacts, previous versions and archives — and whether they disclose source, credentials or structure.
How it is tested — For every known file path, request the conventional backup and editor derivatives of it, and request archive names derived from the application, host and organisation names. Enumerate version control metadata directories, which frequently permit reconstruction of the entire source tree. Where a repository or archive is retrievable, establish what it contains rather than reporting only that it exists, since the finding's severity depends entirely on that.
Prerequisites — The known path list from information gathering; the organisation and application naming conventions, which make archive-name guessing materially more effective.
Indicators — A backup or editor artefact returning source; a version control directory readable; an archive of the application or database retrievable; a previous release still served alongside the current one.
Coverage — WSTG-CONF-04CWE-530CWE-200
Depth — Hybrid Candidate generation and requesting are automated; deriving plausible archive names from the organisation's conventions is not.
WEB-CONF-04 Unauthorised Administrative Interface Access
Objective — Establish which administrative interfaces exist for the application and the platform beneath it, and whether any is reachable by a principal who should not reach it.
How it is tested — Enumerate administrative paths for the identified framework, server and any bundled components, across every in-scope host and port. For each interface found, determine whether it is reachable unauthenticated, reachable with a standard user's session, or restricted by network position only — the last being a control that fails as soon as the attacker is inside. Test whether alternative hostnames, ports or header values bypass a restriction the primary path enforces.
Prerequisites — A standard non-administrative account; the host and port list; where network restriction is claimed, a source address on each side of it.
Indicators — An administrative interface responding unauthenticated; a standard session reaching administrative functions; a restriction bypassed by changing hostname, port or a forwarded-for header.
Coverage — WSTG-CONF-05V4.3.1CWE-284CWE-1188
Depth — Hybrid Path enumeration is automated. Establishing that a network-position control is the only control is manual work.
WEB-CONF-05 HTTP Methods and Verb Tampering
Objective — Determine which HTTP methods each entry point accepts, and whether a method other than the one the interface uses reaches the same functionality while bypassing the checks applied to it.
How it is tested — Enumerate accepted methods per route rather than per host, since framework routing commonly differs from server configuration. Re-issue authenticated and access-controlled requests using alternative and non-standard methods, and using method-override headers and parameters where the framework honours them. Determine whether methods that write state are accepted on routes intended to read, and whether a filter applied to one method is absent from another.
Prerequisites — The route list from entry-point identification; accounts at differing privilege; a client able to issue arbitrary methods.
Indicators — A state-changing method accepted on a read route; an access control enforced for one method and not another; a method-override header changing the effective operation.
Coverage — WSTG-CONF-06WSTG-INPV-03V14.5.1V13.2.1CWE-650
Depth — Hybrid Method enumeration is automated; recognising that an alternative method reaches the same function with a different check is a manual comparison.
WEB-CONF-06 HTTP Strict Transport Security
Objective — Determine whether the application instructs clients to refuse plaintext connections, and whether that instruction covers the hostnames that actually need it.
How it is tested — Request each in-scope host over both plaintext and TLS and record the redirect behaviour and the transport security header, including its duration and whether it extends to subdomains. Establish whether the header is issued on the plaintext response, where it has no effect, or on the secured one where it does. Determine whether any subdomain in scope serves content without it, since the protection is only as broad as its weakest covered name.
Prerequisites — The complete hostname list including subdomains; the ability to reach each over plaintext.
Indicators — The header absent; a duration too short to survive between visits; subdomain coverage omitted where subdomains serve authenticated content; plaintext content served without redirect.
Coverage — WSTG-CONF-07V14.4.5CWE-319CWE-693
Depth — Automated Header presence and parameters are reliably automated. The manual contribution is deciding whether the covered set matches the deployed set.
WEB-CONF-07 Cross-Domain Policy
Objective — Determine whether the application's cross-origin and cross-domain policy declarations permit sites the operator does not control to read authenticated responses.
How it is tested — Retrieve any legacy cross-domain policy files and record the origins they permit. Issue cross-origin requests with a range of origin values — unrelated, prefix and suffix variants of the real origin, and null — and record which are reflected as permitted and whether credentials are allowed alongside. Confirm on authenticated endpoints rather than public ones, since the policy is only interesting where the response contains something worth reading.
Prerequisites — An authenticated session; a client able to set arbitrary origin values; at least one endpoint returning data specific to the session.
Indicators — A policy permitting all origins; an origin reflected without validation; credentials permitted alongside a permissive origin; a null origin accepted.
Coverage — WSTG-CONF-08WSTG-CLNT-07CWE-942CWE-346
Depth — Hybrid Policy retrieval is automated; the reflection and credential combinations need constructing deliberately.
WEB-CONF-08 Role Definition Enumeration
Objective — Establish which roles the application defines, what each is intended to reach, and whether the set as deployed matches the set as designed.
How it is tested — Recover the role list from administrative interfaces, registration and invitation flows, client-side code, and any authorisation data returned to the client. Compare it against the roles the operator believes exist. For each role, establish how it is assigned and whether assignment is restricted to a higher role. Identify roles present in the data model but unreachable through the interface, which are commonly the least reviewed and the most privileged.
Prerequisites — An account at the highest privilege the engagement grants; the operator's own statement of the intended role model, which this test exists to check rather than to assume.
Indicators — Roles present in the deployment but absent from the design; a role assignable by a principal who should not assign it; a privileged role reachable only through a path the interface does not present.
Coverage — WSTG-IDNT-01V4.1.3CWE-266CWE-1220
Depth — Manual Comparing a deployed role model against an intended one requires the intended one, which no scanner has.
WEB-CONF-09 User Registration Process
Objective — Determine whether the registration flow grants only what a new, unproven principal should receive, and whether any part of the resulting identity is under the registrant's control.
How it is tested — Complete registration while recording every field submitted, then resubmit with additional fields the interface does not send — role, group, tenant, verification status and identifier fields — to determine whether any is accepted. Establish whether verification is enforced before the account becomes usable or merely requested. Attempt registration with an identifier already in use, with variants of an existing identifier, and with values reserved for internal use.
Prerequisites — A non-production environment where accounts may be created freely; access to the mailbox or channel used for verification; a proxy.
Indicators — A privilege, tenant or verification attribute accepted from the registrant; an account usable before verification; a registration collision granting access to an existing account; identifier variants resolving to one account.
Coverage — WSTG-IDNT-02V4.1.2CWE-269CWE-915
Depth — Manual The decisive test is submitting fields the interface never sends, which requires knowing what the data model contains.
WEB-CONF-10 Account Provisioning Process
Objective — Determine who may create, modify and grant privilege to accounts, and whether provisioning performed by one principal can produce an account more privileged than the principal creating it.
How it is tested — Exercise every provisioning path — administrative creation, invitation, bulk import, directory synchronisation and any self-service route — and record which principal may invoke each. Attempt to provision at a privilege above the provisioner's own, and into a tenant or group other than the provisioner's. Establish whether credentials generated during provisioning are predictable, transmitted over an appropriate channel, and required to be changed on first use.
Prerequisites — Accounts at more than one administrative level; access to any import or synchronisation mechanism; a non-production environment.
Indicators — An account provisioned above the provisioner's privilege; provisioning into another tenant; a predictable initial credential; an initial credential that never expires.
Coverage — WSTG-IDNT-03V2.5.4CWE-269CWE-1392
Depth — Manual Requires more than one administrative identity and an understanding of the intended provisioning hierarchy.
WEB-CONF-11 Guest and Low-Permission Account Rights
Objective — Establish what a principal at the lowest privilege the application offers can actually reach, as opposed to what the interface offers such a principal.
How it is tested — Using the least privileged account available — and, where one exists, an unauthenticated or guest identity — replay the request set captured from higher-privileged sessions. Establish which data the account can read, which functions it can invoke, and whether it can enumerate other principals, tenants or objects. Include read-only paths that expose identifiers, since an identifier obtained at low privilege is the input to every access-control test that follows.
Prerequisites — The lowest-privilege account the application supports; the request set from higher-privileged sessions; a proxy.
Indicators — A low-privilege session reaching data or functions outside its intended scope; enumeration of other principals or tenants; identifiers disclosed that enable further access-control testing.
Coverage — WSTG-ATHZ-02V4.1.3CWE-276CWE-285
Depth — Manual The comparison is against intent, which has to be supplied rather than inferred.
WEB-CONF-12 Account Suspension and Resumption
Objective — Determine whether suspending, locking or deleting an account actually revokes the access it held, on sessions and tokens already issued as well as on future sign-in attempts.
How it is tested — Establish an authenticated session and any long-lived tokens the account can hold, then suspend the account through each available route. Re-issue requests on the existing session and with each token, and attempt to sign in again. Repeat for deletion and for role downgrade. Where resumption exists, determine whether it restores the previous privilege exactly, and whether any credential valid before suspension becomes valid again.
Prerequisites — An account that may be suspended and resumed; an administrative account able to perform it; a non-production environment; a proxy retaining the pre-suspension session.
Indicators — An existing session surviving suspension; an issued token still honoured; resumption restoring more privilege than was held; a suspended account still reachable through an alternative authentication channel.
Coverage — WSTG-IDNT-03V3.3.1V3.3.4CWE-613CWE-284
Depth — Manual The test only means anything if the session is captured before suspension and replayed after it, which is a sequence no scanner constructs.
What we need from you
The full in-scope hostname and port list, including staging and administrative names, since the weaknesses in this category concentrate on the hosts nobody considers production; the ability to complete a registration and, where the application supports it, an account-suspension cycle in a non-production environment; and written confirmation of which hosts may be probed.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- WSTG-CONF-02 — Test Application Platform Configuration
- V14.3.2 — Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.
- CWE-1188 — Initialization of a Resource with an Insecure Default
- WSTG-CONF-03 — Test File Extensions Handling for Sensitive Information
- V12.5.1 — Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.
- V12.2.1 — Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.
- CWE-434 — Unrestricted Upload of File with Dangerous Type
- WSTG-CONF-04 — Review Old Backup and Unreferenced Files for Sensitive Information
- CWE-530 — Exposure of Backup File to an Unauthorized Control Sphere
- CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
- WSTG-CONF-05 — Enumerate Infrastructure and Application Admin Interfaces
- V4.3.1 — Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.
- CWE-284 — Improper Access Control
- WSTG-CONF-06 — Test HTTP Methods
- WSTG-INPV-03 — Testing for HTTP Verb Tampering
- V14.5.1 — Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.
- V13.2.1 — Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.
- CWE-650 — Trusting HTTP Permission Methods on the Server Side
- WSTG-CONF-07 — Test HTTP Strict Transport Security
- V14.4.5 — Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.
- CWE-319 — Cleartext Transmission of Sensitive Information
- CWE-693 — Protection Mechanism Failure
- WSTG-CONF-08 — Test RIA Cross Domain Policy
- WSTG-CLNT-07 — Test Cross Origin Resource Sharing
- CWE-942 — Permissive Cross-domain Security Policy with Untrusted Domains
- CWE-346 — Origin Validation Error
- WSTG-IDNT-01 — Test Role Definitions
- V4.1.3 — Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
- CWE-266 — Incorrect Privilege Assignment
- CWE-1220 — Insufficient Granularity of Access Control
- WSTG-IDNT-02 — Test User Registration Process
- V4.1.2 — Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
- CWE-269 — Improper Privilege Management
- CWE-915 — Improperly Controlled Modification of Dynamically-Determined Object Attributes
- WSTG-IDNT-03 — Test Account Provisioning Process
- V2.5.4 — Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").
- CWE-1392 — Use of Default Credentials
- WSTG-ATHZ-02 — Testing for Bypassing Authorization Schema
- CWE-276 — Incorrect Default Permissions
- CWE-285 — Improper Authorization
- V3.3.1 — Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.
- V3.3.4 — Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.
- CWE-613 — Insufficient Session Expiration
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.