The security assessment and pen-test report

What it is

The security assessment benchmarks your website against the published hardening guidelines — the WordPress.org Hardening WordPress guide, the Laravel security docs, the PHP security guidance, and the OWASP Secure Headers and Web Security Testing guidance — and gives you a pen-test report: a score out of 100, findings grouped by severity (critical, high, medium, low, info), and for each one the guideline it fails, where it was found, why it matters and the exact fix for your platform.

It is defensive and safe by design. It is read-only and non-destructive: it never changes or deletes anything, never tries to break in, and runs only on a website you have connected to MiseGuard and consented to assess. It never runs against a site you do not own.

Running one

1. Open the site and click Run assessment (you need the manage permission; not available while viewing as a customer).
2. What we'll check — a short list of the groups. Click Continue.
3. Your authorisation — read the consent and tick the box. Your authorisation is recorded and signed with who you are, when, and the exact website. Click Authorise and run.
4. Running — about a minute. The report opens when it is done.

One assessment runs at a time in each workspace (your MiseGuard administrator can allow more). While one runs, Run now on another site says so: start it when the first has finished, a few minutes later. A scheduled re-assessment waits for the next round in the same way.

A website with no verified connector is offered the passive check instead: the public signals a browser already sees (certificate, security headers, platform from the public page). The full active assessment needs the connector and your consent.

What it checks

• Transport & headers: TLS version and certificate, HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, cookie Secure/HttpOnly/SameSite, mixed content and CORS.
• Exposed files: a fixed list of paths that should never be public — .env, .git, backups and database dumps, debug logs, phpinfo, application logs, admin tools and version files. It only ever requests this list, and only with GET/HEAD.
• Your platform's hardening: WordPress (XML-RPC, username enumeration, directory indexing, the dashboard file editor, debug), Laravel (debug mode, Telescope/Horizon/Ignition exposure) and PHP (end-of-life version, error display, version banners). Where your connector already knows the answer, we read it from your site rather than guessing from outside.
• Safe, consented probes: we send a small, capped number of deliberately-wrong, made-up sign-ins to confirm your login lockout fires (and stop the moment it does); a harmless marker to see whether input is reflected unescaped; and a marker in redirect links to spot an open redirect. None of these is a working attack, and nothing harmful is ever stored.

The report, the PDF and sharing

Each finding opens to show the guideline, where it is, why it matters and the fix on each platform, then three ways to fix it. You can download a branded PDF or a CSV, and create a private share link that anyone with the link can read without signing in. Share links are private by default, end after a while, and you can revoke one at any time.

Three ways to fix a finding

• I'll fix it myself: the exact steps for your site's platform (WordPress, Laravel, a PHP site, or a hosted platform such as Shopify or Wix, where the steps say what the platform lets you change), ending with Check again.
• Help me do it: the same steps one at a time; tick each off, then Check again.
• Do it for me: where your site's MiseGuard or {brand} connector can fix it safely, by turning on one of the site's own hardening switches: Turn off the file editor, Turn off XML-RPC, Stop visitors listing usernames, One message for a wrong username or password, Hide the WordPress version (WordPress) and Send security headers (WordPress, Laravel and PHP sites). The review shows the switch going from Off to On, what it changes for your visitors and apps (for example, apps that use XML-RPC stop working), and the other findings the same switch fixes.

Check again reads only what the finding was about (the home page's headers, the one address, or your site's own report), not a whole new assessment, and marks the finding Fixed when it is gone.

Do it for me, step by step

1. Press Do it for me on the finding and read the review.
2. An owner or admin of the workspace presses Approve and fix it. Anyone else who manages the project presses Ask an owner or admin to approve: nothing changes on your site until one of them approves it on the same finding.
3. Your site's connector turns the switch on and keeps what it was before. A switch MiseGuard's own settings hold for your site (XML-RPC, usernames and sign-in messages) is switched on there instead, and your site picks it up at its next check-in, a minute or two later.
4. A minute or so later MiseGuard checks the site again (up to three times, waiting longer each time) and the finding shows Fixed and checked, or Still seen with what is left (a page cache, for example: clear it and press Check again).
5. Undo puts the switch back exactly as it was, at any time. Each fix is a change you can also find under your site's changes, or in MiseGuard's settings history.

Your connector needs version 0.47.0 or later of the {brand} WordPress plugin (1.6.0 of the MiseGuard plugin), 0.37.0 of the Laravel package or 0.31.0 of the PHP connector, and the site's Firewall permission. Without them the finding says what is missing and keeps its steps.

Findings with no automatic fix

Everything else is fixed by a person, and the finding says why: deleting or moving files (backups, logs, .env, .git), your host's PHP, TLS and web server settings, wp-config.php and .env (the connector never edits them), your app's own code, a Content-Security-Policy, HSTS and the browser features to switch off (each depends on your site), and sign-in protection, which is MiseGuard's Login protection setting. Do it for me then offers our team or the steps.

Keeping it current

Leave the monthly re-assessment on and we check the site on a schedule and raise an alert (through your usual MiseGuard alerts) when a new high or critical risk appears. The history shows what changed since last time, and the site's MiseGuard security score includes the assessment.

Good to know

• Severity is decided by fixed rules, the same every time; a staff policy can tune a band, but it is never decided by AI.
• Explained by AI: after an assessment, the AI rewrites the "why it matters" text of the most serious findings (twelve by default) in plainer words, marked Explained by AI in the report. It never changes a finding, its severity, its fix or the score, and it only sees our own wording of each finding, never your site's content. It uses one credit of your workspace per assessment; with no credits left, or when your administrator switched it off, the written explanation is shown instead.
• Everything is paced and bounded: a low request rate, a page budget and a time limit per run, with a staff stop switch.
• Past assessments are kept for 400 days unless your MiseGuard administrator set another number, with their findings and share links; older ones are deleted every night. Each site's newest assessment always stays, so the next one can still say what changed. The deletion is listed in your Deletion calendar.
• While the assessment is switched off for your workspace it shows a Beta badge with Ask for early access, never an error. The same goes for Do it for me while your MiseGuard administrator has it switched off.
• While a project is archived nothing is changed on its site, and its connector shows Paused because the project was archived until you restore it.