Wagtail Penetration Testing

Wagtail permissions are set once on a page in the tree and apply automatically to every page beneath it, including ones created later. A boundary drawn one level too high on the tree reaches further than intended.

Why Wagtail security comes down to where permissions sit in the tree

Wagtail extends Django’s own permission system with six page-specific rights, Add, Edit, Publish, Lock, Unlock and Bulk delete, and every one of them is set on a page in the tree and automatically applies to everything beneath it, including pages that do not exist yet. Add lets a user edit and delete only the pages they created; Edit reaches every page in scope regardless of owner; and Publish is independent of both, so a user without it can prepare changes but cannot make them live without going through moderation. Wagtail’s own permissions documentation also notes that drafts stay visible only to users holding Edit or Publish, which is where a shared or forwarded preview link can quietly widen access. We test where each group’s boundary actually sits against where the page tree was meant to draw the line.

Content that should not be public does not have to be marked so by accident. A page can be restricted to any logged-in user, to a shared password, or to members of specific groups, and Wagtail’s documentation is explicit that the shared password option is stored in plain text and shared between everyone given it. Documents inherit the same three restriction types from the collection they sit in, but that check only holds when WAGTAILDOCS_SERVE_METHOD is left on serve_view; the direct and redirect alternatives serve files straight from storage and trade away the per-request permission check for performance, which is why Wagtail’s documentation calls for the underlying documents directory to be blocked at the web server regardless of which method is configured. We test which restriction type and serve method are actually live, not which one the settings file implies.

A single Wagtail installation can run several sites side by side from the same page tree, and the Wagtail API v2 adds a further surface across all of them: a field only reaches the response once it is explicitly listed in a page model’s api_fields, split between body_fields and meta_fields, and a field already available in meta_fields still needs its own entry in nested_default_fields before it appears on a related page nested inside another result. We test whether that field-by-field opt-in has left something exposed that should not be public, whether a permission boundary that holds in the admin also holds through the API, and whether custom Django views or StreamField blocks, including the built-in RawHTMLBlock that Wagtail’s own documentation says should only go to fully trusted editors, carry the same checks as the rest of the organisation’s site.