Công cụ miễn phí, không cần tài khoản

Free WordPress Security Configuration Checker

Check eight externally observable WordPress configuration areas: XML-RPC, wp-login.php, debug leakage, directory listing, version disclosure, security headers, REST user enumeration, and sensitive public paths.

Còn được gọi là: WordPress hardening checker, XML-RPC and REST API test

Bằng chứng được hiển thị với nguồnKhông cần tài khoảnKhông có chỉ số nào được tạo ra.

Chạy một kiểm tra thực tế ở trên

Gửi một URL công khai, tên miền, hoặc từ khóa. Novaverb sẽ chỉ hiển thị bằng chứng mà công cụ này thực sự có thể lấy hoặc đo lường.

Mô hình bằng chứng

Biết điều gì mà kết quả chứng minh

This check captures public HTTP evidence for eight WordPress configuration areas: XML-RPC, the standard login path, debug leakage, directory listing, version disclosure, six response headers, REST API user enumeration and selected sensitive paths. It keeps each observation separate and publishes no general security score.

1. Nguồn

Bounded live HTTP observations from the submitted public WordPress origin. Kết quả xác định nguồn gốc của bằng chứng.

2. Ranh giới

This is a non-intrusive configuration review of selected public HTTP responses. It does not test passwords, exploit vulnerabilities, enumerate plugins, or prove that a WordPress site is secure.

3. Hành động tiếp theo

Sử dụng phát hiện để xác minh một vấn đề, sau đó kết nối một không gian làm việc khi bạn cần lịch sử, giám sát hoặc phân tích toàn bộ trang web.

How to read this WordPress configuration result

Observation, not exploitation

The checker recognizes selected public response signatures. It sends no attack payload, login attempt, password test or component enumeration request.

No composite security score

Each of the eight areas stands on its own evidence. A clean header result cannot cancel an exposed debug log, and an unavailable response never becomes a pass.

Fix, deploy, re-check

Prioritize exposed logs and sensitive files, then public user enumeration and unnecessary endpoints. Re-run the exact check after deploying each configuration change.

Nhận câu trả lời đúng

Điều gì cần gửi - và điều gì cần tránh

Submit a public WordPress domain or any URL on that site. The checker normalises the address to the final public origin before requesting WordPress paths. Private and reserved targets are refused, and the result may say WordPress was not confirmed when the site hides or changes all recognizable public signals.

Sử dụng nó như thế này

your-wordpress-site.comA public WordPress domain works, and the checker normalizes the address before the bounded requests.

https://www.your-wordpress-site.com/blogA full page URL works too; WordPress configuration paths are checked at the final public origin.

Tránh điều này

localhost / 10.0.0.8Private and internal targets are refused by the public-IP safety boundary.

Expecting a vulnerability scanThis tool checks selected public configuration evidence only; it does not exploit, authenticate, or enumerate installed components.

Phương pháp công khai

Chính xác cách kết quả này được sản xuất

Every request passes through the public-IP safety boundary and every redirect target is checked again. The checker recognizes specific response signatures rather than treating every HTTP 200 as exposure, runs a bounded set of paths, and discards raw response bodies before the result is stored or displayed.

Chúng tôi lấy địa chỉ công khai đã gửi thông qua kiểm tra an toàn IP cố định và kiểm tra lại mọi điểm đến chuyển hướng.
We request a bounded WordPress path set and recognize exact login, XML-RPC, REST, directory-index, debug and sensitive-file signatures.
We read the homepage for WordPress version signals and six selected browser security headers.
We discard raw response bodies and report eight named configuration observations without creating a composite security score.

Xây dựng trên các tiêu chuẩn công khai

Các tiêu chuẩn quốc tế mà kiểm tra này áp dụng

WordPress documentation defines XML-RPC and REST API behavior, while RFC 9110 defines the HTTP responses observed. The response-header section applies the selected OWASP Secure Headers set. These references describe configuration surfaces; none turns a public response into proof of a vulnerability.

WordPressXML-RPC

WordPress XML-RPC support

Recognises whether the standard public XML-RPC endpoint answers with a WordPress XML-RPC signature.

Đọc thông số kỹ thuật

WordPressREST API

WordPress REST API

Checks REST discovery separately from whether the public users endpoint returns account identifiers.

Đọc thông số kỹ thuật

IETFRFC 9110

HTTP Semantics

Reads each bounded path's response status while preserving unavailable and restricted outcomes.

Đọc thông số kỹ thuật

OWASPSecure Headers

OWASP Secure Headers Project

Reports presence of the six selected response-header controls without claiming their policy values are complete.

Đọc thông số kỹ thuật

Chúng tôi chỉ liệt kê một tiêu chuẩn khi công cụ này thực sự đọc hoặc đo lường theo đó. Khi một tín hiệu nằm ngoài kiểm tra trực tiếp, kết quả sẽ nói rõ điều đó thay vì ngụ ý rằng có sự bao phủ.

Câu hỏi thường gặp

WordPress Security Configuration Checker Câu hỏi thường gặp

What does the WordPress Security Configuration Checker inspect?

It observes eight public configuration areas: XML-RPC, wp-login.php, debug output, directory listing, WordPress version disclosure, six security headers, the REST API user endpoint, and selected sensitive WordPress paths.

Is this a WordPress vulnerability scanner?

No. The checker sends bounded public HTTP requests only. It does not exploit vulnerabilities, test passwords, enumerate plugins or themes, inspect source code, or look up known software vulnerabilities.

Should XML-RPC always be disabled?

Not always. XML-RPC can support publishing clients, integrations and pingbacks. If nothing you use needs it, restrict or disable it; if it must stay public, protect it with rate limiting and monitoring.

Is a public wp-login.php page automatically insecure?

No. The standard login page is normally public, so reachability is a review item rather than proof of a defect. Use strong passwords, multi-factor authentication, rate limiting and monitoring instead of relying on a hidden URL.

How does the checker detect exposed WP_DEBUG output?

It looks for recognizable PHP and WordPress error signatures in the captured homepage and public debug.log response. It never displays or stores the raw log or configuration-file contents.

What counts as WordPress directory listing?

The checker requests selected wp-content directories and looks for an actual generated index page, such as an Index of page with a parent-directory listing. A normal application response is not labeled as directory listing.

How can WordPress disclose its version?

A page can disclose a WordPress version through its generator metadata. Removing that metadata reduces easy fingerprinting, but installing security updates remains the important control.

Is the WordPress REST API unsafe?

No. The REST API is a normal WordPress feature. The relevant observation is whether the public users endpoint returns account identifiers; the checker reports REST availability and user enumeration separately.

Which sensitive WordPress paths are checked?

The bounded path set covers the public readme and license files, the install and setup screens, debug.log, and one common wp-config.php backup name. Only recognized content is labeled exposed, and raw sensitive content is discarded.

Does a clean configuration result prove the site is secure?

No. It only means the selected public observations did not show those configuration exposures at that moment. Plugin vulnerabilities, authorization flaws, malware, weak accounts and server-side issues require separate authorized testing.

Nhiều kiểm tra miễn phí hơn