How can I verify that DNN Defender is protecting my website?

A security dashboard is a useful starting point, but the strongest assurance comes from a test you can repeat on a copy of your own website. DNN Defender lets an administrator follow a controlled security scenario from the first signal to the recorded decision and its outcome. That is more meaningful than relying on a product screenshot or a general detection percentage.

Start with a controlled copy of your site

Use an isolated lab that reflects your DNN version, installed modules, theme, and protection settings. Take a restorable snapshot before testing. Use an approved set of known-malicious and known-good samples; keep the lab restricted to authorized testers. Do not run malware or perform destructive tests on a customer-facing website. The detailed test cases and samples can be shared privately with the site's authorized administrator rather than published as attack instructions.

Record the DNN and DNN Defender versions, enabled protection modes, monitored locations, and control-health status before each test. A test result is meaningful only when the control being evaluated was active at the time.

Verify request protection

Run a safe, controlled HTTP test through an application workflow in the lab. In an observation mode, check that the WAF or Advisory Shield records the relevant event. In a blocking mode, compare the HTTP response with the matching Blocked event, rule or advisory identifier, and timestamp. The response and event should tell the same story. A recorded observation is evidence of detection; a matching blocked outcome is evidence that the request was denied.

The optional WAF technical self-test is useful for checking rule behavior. For operational assurance, also verify the actual lab workflow and its recorded outcome.

Verify file scanning with positive and benign controls

Run an on-demand scan against a small, documented test set: a known-malicious ASP.NET sample and comparable legitimate server-side files. Review the finding details, including the file, decision, and Rule/AST evidence, with AI evidence where that edition and configuration apply. The benign controls matter: a useful security decision should be explainable, not merely produce an alert whenever it sees a server-side extension.

If you want to assess how the product handles changed or unfamiliar samples, use additional approved samples in the same isolated lab and retain their hashes and expected classifications. There is no need to execute a web shell to verify that the scanner recognizes it.

Verify realtime decisions and containment

For each file-protection mode you intend to use, place controlled samples into the monitored lab scope and follow the recorded sequence: file change, scan finding, policy decision, alert, and—where the configured protection policy calls for it—quarantine. Compare the original file state with the quarantine record. Include an approved, legitimate change in the test set so you can evaluate normal deployment behavior as well as threat detection.

On-demand scanning, realtime monitoring, and automatic containment answer different operational questions. Record which mode produced each result rather than treating every alert as a blocked attack. If email alerts are configured, verify that the message reflects the same finding and outcome shown in the dashboard.

Verify file integrity against an approved baseline

Create a trusted FIM baseline after reviewing the lab's starting state. Make a few authorized test changes and run an integrity check. Confirm that additions, modifications, and removals are reported against that baseline with the correct file and time. FIM supplies independent change evidence; the malware scanner supplies the security assessment of a file's contents.

Keep a repeatable test record

For each case, retain the software versions, mode, test-case identifier, sample hash, UTC time, HTTP or file outcome, matching DNN Defender event, and before-and-after evidence. Repeat this small suite after major DNN, skin, module, or policy changes. It gives your team a practical answer to the question "What did DNN Defender actually do on our site?"—and a record you can review again whenever the website changes.