ARK. 1System · Standardy
OWASP ASVS — które wymaganie bezpieczeństwa strona łamie, gdy Finding jest otwarty.
ASVS (Application Security Verification Standard) to lista wymagań, które aplikacja webowa ma spełniać, podzielona na trzy poziomy: L1 — minimum dla każdej strony, L2 — aplikacje z danymi, które trzeba chronić, L3 — systemy krytyczne. CWE mówi, jaka to słabość, OWASP Top 10 — do której grupy ryzyk należy. ASVS mówi, którego wymagania strona nie spełnia, i to wprost opisuje brak nagłówka, stary certyfikat albo plik kopii na widoku, gdzie CWE bywa naciągane.
Źródło: OWASP ASVS 5.0.0, eksport CSV, odczyt 30.09.2026. Identyfikator z wersją, jak każe rozdział „How to Reference ASVS Requirements”: v5.0.0-3.4.1. Przypisanie typu do wymagania jest oceną LAB247, nie OWASP. Inne osie tej samej klasyfikacji: OWASP Top 10, MITRE ATT&CK, OCSF, SSVC.
- Wymagania w użyciu
- 23z 345 w ASVS 5.0.0
- Typy Findingów
- 46ze 163 w katalogu
- L1 / L2 / L3
- 7 / 12 / 4poziom wymagania
- Rozdziały
- 7nagłówki, pliki, logowanie, TLS, konfiguracja…
TAB. 1Wymaganie → typy FindingówASVS 5.0.0 · 23 wymagań
| Wymaganie | L | Rozdział | Treść (OWASP, po angielsku) | Typy LAB247 |
|---|---|---|---|---|
| v5.0.0-3.4.1 | 1 | 3.4 Browser Security Mechanism Headers | Verify that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age of at least 1 year must be defined, and for L2 and up, the policy must apply to all subdomains as well. | missing_hsts |
| v5.0.0-3.4.3 | 2 | 3.4 Browser Security Mechanism Headers | Verify that HTTP responses include a Content-Security-Policy response header field which defines directives to ensure the browser only loads and executes trusted content or resources, in order to limit execution of malicious JavaScript. As a minimum, a global policy must be used which includes the directives object-src 'none' and base-uri 'none' and defines either an allowlist or uses nonces or hashes. For an L3 application, a per-response policy with nonces or hashes must be defined. | missing_csp |
| v5.0.0-3.4.4 | 2 | 3.4 Browser Security Mechanism Headers | Verify that all HTTP responses contain an 'X-Content-Type-Options: nosniff' header field. This instructs browsers not to use content sniffing and MIME type guessing for the given response, and to require the response's Content-Type header field value to match the destination resource. For example, the response to a request for a style is only accepted if the response's Content-Type is 'text/css'. This also enables the use of the Cross-Origin Read Blocking (CORB) functionality by the browser. | missing_nosniff |
| v5.0.0-3.4.5 | 2 | 3.4 Browser Security Mechanism Headers | Verify that the application sets a referrer policy to prevent leakage of technically sensitive data to third-party services via the 'Referer' HTTP request header field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes. Sensitive data could include path and query data in the URL, and for internal non-public applications also the hostname. | missing_referrer_policy |
| v5.0.0-3.4.6 | 2 | 3.4 Browser Security Mechanism Headers | Verify that the web application uses the frame-ancestors directive of the Content-Security-Policy header field for every HTTP response to ensure that it cannot be embedded by default and that embedding of specific resources is allowed only when necessary. Note that the X-Frame-Options header field, although supported by browsers, is obsolete and may not be relied upon. | missing_xframe |
| v5.0.0-5.3.1 | 1 | 5.3 File Storage | Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly with an HTTP request. | uploads_executable |
| v5.0.0-6.3.3 | 2 | 6.3 General Authentication Security | Verify that either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms, must be used in order to access the application. For L3, one of the factors must be a hardware-based authentication mechanism which provides compromise and impersonation resistance against phishing attacks while verifying the intent to authenticate by requiring a user-initiated action (such as a button press on a FIDO hardware key or a mobile phone). Relaxing any of the considerations in this requirement requires a fully documented rationale and a comprehensive set of mitigating controls. | posture_no_2fa_admins |
| v5.0.0-6.3.4 | 2 | 6.3 General Authentication Security | Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | exposure_xmlrpc |
| v5.0.0-6.3.8 | 3 | 6.3 General Authentication Security | Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality must also have this protection. | exposure_users_enum · exposure_author_enum |
| v5.0.0-12.1.1 | 1 | 12.1 General TLS Security Guidance | Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol must be the preferred option. | tls_przestarzaly |
| v5.0.0-12.2.1 | 1 | 12.2 HTTPS Communication with External Facing Services | Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications. | redirect · mixed_content |
| v5.0.0-12.2.2 | 1 | 12.2 HTTPS Communication with External Facing Services | Verify that external facing services use publicly trusted TLS certificates. | ssl · ssl_hostname_mismatch |
| v5.0.0-13.4.1 | 1 | 13.4 Unintended Information Leakage | Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself. | exposure_git |
| v5.0.0-13.4.2 | 2 | 13.4 Unintended Information Leakage | Verify that debug modes are disabled for all components in production environments to prevent exposure of debugging features and information leakage. | posture_debug_display_on · exposure_path_leak |
| v5.0.0-13.4.3 | 2 | 13.4 Unintended Information Leakage | Verify that web servers do not expose directory listings to clients unless explicitly intended. | exposure_directory_listing |
| v5.0.0-13.4.6 | 3 | 13.4 Unintended Information Leakage | Verify that the application does not expose detailed version information of backend components. | exposure_readme |
| v5.0.0-13.4.7 | 3 | 13.4 Unintended Information Leakage | Verify that the web tier is configured to only serve files with specific file extensions to prevent unintentional information, configuration, and source code leakage. | exposure_env · exposure_wpconfig_bak · exposure_wpconfig_tilde · exposure_backup_archive · exposure_sql_dump · exposure_htaccess_bak · exposure_dev_manifest · exposure_ds_store |
| v5.0.0-15.2.1 | 1 | 15.2 Security Architecture and Dependencies | Verify that the application only contains components which have not breached the documented update and remediation time frames. | vuln_cve · vuln_cve_krytyczna · vuln_wp_core · vuln_wp_core_krytyczna · eol_cms · posture_php_eol · outdated_php · outdated_plugin · outdated_theme · outdated_wp |
| v5.0.0-15.2.2 | 2 | 15.2 Security Architecture and Dependencies | Verify that the application has implemented defenses against loss of availability due to functionality which is time-consuming or resource-demanding, based on the documented security decisions and strategies for this. | exposure_wpcron |
| v5.0.0-15.2.3 | 2 | 15.2 Security Architecture and Dependencies | Verify that the production environment only includes functionality that is required for the application to function, and does not expose extraneous functionality such as test code, sample snippets, and development functionality. | exposure_phpinfo · exposure_db_console · risky_tool_present · posture_file_edit_allowed |
| v5.0.0-15.2.4 | 3 | 15.2 Security Architecture and Dependencies | Verify that third-party components and all of their transitive dependencies are included from the expected repository, whether internally owned or an external source, and that there is no risk of a dependency confusion attack. | plugin_unknown_source · wtyczka_administracyjna_niezweryfikowana |
| v5.0.0-16.4.2 | 2 | 16.4 Log Protection | Verify that logs are protected from unauthorized access and cannot be modified. | exposure_debug_log |
| v5.0.0-16.5.1 | 2 | 16.5 Error Handling | Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens. | exposure_path_leak |
TAB. 2Niespełnione wymagania bez odpowiednika w ASVSdlaczego pusto
| Typ | Powód |
|---|---|
| missing_permissions_policy | ASVS 5.0.0 nie wymaga nagłówka Permissions-Policy (rozdział 3.4 go nie wymienia) |
| open_registration | ustawienie funkcjonalne WordPressa; ASVS nie zabrania rejestracji kont |
| posture_registration_open | jak open_registration |
| ssl_expiry | certyfikat jest jeszcze ważny — 12.2.2 nie jest naruszone, dopóki nie wygaśnie |
| dns_spf_missing | uwierzytelnianie poczty domeny — poza zakresem ASVS (aplikacja, nie DNS) |
| dns_dmarc_missing | jak dns_spf_missing |
| dns_mail_auth_removed | jak dns_spf_missing |
| cron_dependency_at_risk | ryzyko dla monitoringu, nie wymaganie wobec aplikacji |
| posture_cron_orphans | higiena bazy WordPressa bez odpowiednika w ASVS |
TAB. 3Jak czytaćgranice osi
- Kiedy typ dostaje ASVS
- gdy Finding tego typu oznacza, że strona nie spełnia konkretnego wymagania — klasa OCSF Compliance albo Vulnerability. Wykrycia (infekcja, nowy administrator) nie mają wymagania: to ślad działania, nie brak zabezpieczenia.
- Poziom L
- poziom z ASVS, nie waga Findingu. Brak Content-Security-Policy (L2) może być groźniejszy na konkretnej stronie niż brak HSTS (L1) — o tym mówi Severity.
- Test pilnuje
- każde wymaganie w użyciu pochodzi z eksportu OWASP; katalog nie trzyma wymagań bez typu; typ klasy Compliance bez ASVS musi mieć powód w TAB. 2.
- Gdzie widać
- karta Findingu w panelu (TAB. Klasyfikacja), API skanera (pole standardy.asvs), opis w Audycie AI.