Handler and API security
Understand why DNN Defender endpoints can be probed and how authorization, anti-forgery, verbs, one-time exports, and response hardening protect them.
Not rated yet
An .ashx or .asmx URL is not secret. Browsers, JavaScript, proxy logs, scanners, historical
indexes, and error telemetry can reveal an endpoint, and predictable application structure can be
fuzzed. DNN Defender therefore does not use a long filename as an access-control mechanism.
Every sensitive handler authenticates and authorizes the caller before parsing an action, reading
security data, running an assembly scan, sending mail, or returning an export. State-changing
operations require the expected HTTP verb and DNN anti-forgery token. Anonymous probes receive an
empty 404; authenticated non-Host accounts receive 403; wrong verbs receive 405 after authorization
so anonymous callers cannot enumerate operations by status differences.
Responses use no-store/no-cache and defensive content/frame/referrer headers where permitted by
the host. Exceptions are written to the DNN event log without returning stack traces or internal
paths.
CSV exports use a random one-time nonce bound to the same Host session. The server removes the
content, filename, and nonce before writing the response, so replay, copying the URL to another
session, or using an expired session returns 404.
The WAF remains defense in depth. Exact Host-authenticated DNN Defender requests may be excluded
from generic anomaly noise only after the targeted advisory checks have run; anonymous and
non-Host probes remain visible. Handler authorization must remain effective even when the generic
WAF is disabled.
Was this page helpful?