Changes for page What an XWiki Security Review Should Actually Include

Last modified by Agnease on 2026/06/08 18:44

Manage
- Copy
Actions
- Export
- Print Preview
Viewers
- Source
- Siblings
- Content
- Comments
- Attachments (1)
- History
- Information
- Likes

From 3.7 to 3.8

From version 3.8

edited by Agnease
on 2026/06/08 18:25

Change comment: There is no comment for this version

To version 3.12

edited by Agnease
on 2026/06/08 18:44

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -28,9 +28,12 @@
            <h4>In this guide</h4>
            <ul>
              <li><a href="#why-it-matters">Why it matters</a></li>
++            <li><a href="#quick-self-check">Quick self-check</a></li>
              <li><a href="#what-to-review">What to review</a></li>
++            <li><a href="#common-findings">Common findings</a></li>
              <li><a href="#security-checklist">Security checklist</a></li>
              <li><a href="#review-output">What the review should produce</a></li>
++            <li><a href="#readiness-checklist">What to prepare</a></li>
              <li><a href="#when-to-review">When to run a review</a></li>
              <li><a href="#security-review-faq">FAQ</a></li>
            </ul>
@@ -45,6 +45,11 @@
            </p>
            <p>
++            An XWiki security review is a practical audit of the platform configuration, access model,
++            authentication setup, installed extensions, custom code, infrastructure and recovery procedures.
++          </p>
++
++          <p>
              Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
              forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
              weak fallback access or backup assumptions that were never tested.
@@ -59,10 +59,9 @@
            </div>
            <p>
--            An XWiki security review is a structured assessment of the wiki platform, its configuration,
--            access model, authentication mechanisms, extensions, customizations and operational setup.
--            The goal is to identify risks, maintenance weaknesses and upgrade blockers before they affect
--            users or business-critical content.
++            The value of the review is not only to find technical issues. It is to understand how the instance is actually
++            used, where risk has accumulated over time, and what should be cleaned up before the next upgrade, migration,
++            authentication change or business-critical rollout.
            </p>
            <div class="resource-note">
@@ -86,10 +86,34 @@
            </p>
            <p>
--            A security review helps identify risks before they become incidents, upgrade blockers or maintenance
--            surprises. It also gives administrators a clearer view of the current state of the instance.
++            In real XWiki instances, security problems are rarely caused by a single visible mistake. They often come from
++            years of small configuration decisions: one temporary group, one local right exception, one old extension, one
++            undocumented script, one backup procedure that nobody has tested recently.
            </p>
++          <h2 id="quick-self-check">Quick self-check: does your XWiki need a security review?</h2>
++
++          <p>
++            Your XWiki instance may need a security review if one or more of these situations sound familiar.
++          </p>
++
++          <ul class="resource-checklist">
++            <li>You are not sure who currently has admin, script or programming rights.</li>
++            <li>The instance has not been upgraded regularly or the upgrade path is unclear.</li>
++            <li>SSO, LDAP, OIDC or SAML was configured years ago and not reviewed recently.</li>
++            <li>Custom scripts, templates, macros or extensions exist but are not clearly documented.</li>
++            <li>Groups and page-level rights have grown organically over several years.</li>
++            <li>Backups exist, but the restore process has not been tested or documented.</li>
++            <li>A new team inherited the instance and has to guess how rights, extensions or customizations were configured.</li>
++          </ul>
++
++          <div class="resource-note">
++            <p>
++              <strong>Practical signal:</strong> if the instance works but nobody can clearly explain the access model,
++              the customizations and the recovery process, the risk is not only technical. It is operational.
++            </p>
++          </div>
++
            <h2 id="what-to-review">What should be reviewed</h2>
            <h3>1. Version and upgrade status</h3>
@@ -122,7 +122,7 @@
              of small exceptions that nobody reviewed later.
            </p>
--         <p>
++          <p>
              For a deeper look at this topic, see
              <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
              For a practical starting point, see
@@ -176,9 +176,41 @@
                A structured review can check versions, access rights, authentication,
                extensions, custom code, infrastructure, backups and operational practices.
              </p>
--            <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
++            <a class="btn btn-default" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
            </div>
++          <h2 id="common-findings">Common findings in real XWiki security reviews</h2>
++
++          <p>
++            In real XWiki instances, security risks are often not caused by one major mistake. They usually come from
++            configuration decisions that were reasonable at the time but were never reviewed together later.
++          </p>
++
++          <ul class="resource-checklist">
++            <li>Old administrator accounts that are still active.</li>
++            <li>Script or programming rights granted to users who no longer maintain the platform.</li>
++            <li>Groups created for old projects that still grant access.</li>
++            <li>Page-level rights added as exceptions and never documented.</li>
++            <li>Custom Velocity or Groovy code that is business-critical but undocumented.</li>
++            <li>Extensions installed years ago without a clear owner or upgrade validation process.</li>
++            <li>SSO configured correctly for login, but not reviewed together with XWiki groups.</li>
++            <li>Backup jobs scheduled automatically, but restore expectations never tested.</li>
++            <li>Production changes performed without a staging or rollback habit.</li>
++          </ul>
++
++          <h2 id="what-this-is-not">What this review is not</h2>
++
++          <p>
++            A security review is not a one-click scan and it is not limited to checking the installed XWiki version.
++            Automated checks can help, but they cannot fully explain why a group has access, whether a custom script is still
++            needed, or whether a restore procedure would actually work during an incident.
++          </p>
++
++          <p>
++            The review should combine technical checks with context: how the wiki is used, which areas are sensitive, which
++            users administer it, what customizations matter and what the organization expects during an incident or upgrade.
++          </p>
++
            <h2 id="security-checklist">XWiki security review checklist</h2>
            <p>
@@ -202,8 +202,8 @@
            <h2 id="review-output">What the review should produce</h2>
            <p>
--            A useful security review should not only produce a list of detected problems. It should produce a practical action
--            plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
++            A useful security review should not only produce a list of detected problems. It should produce a practical
++            action plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
            </p>
            <p>
@@ -220,6 +220,33 @@
              </p>
            </div>
++          <h3>Example review finding</h3>
++
++          <table class="table table-bordered table-striped">
++            <thead>
++              <tr>
++                <th>Finding</th>
++                <th>Risk</th>
++                <th>Recommended action</th>
++                <th>Priority</th>
++              </tr>
++            </thead>
++            <tbody>
++              <tr>
++                <td>Several users have script rights but are no longer responsible for XWiki administration.</td>
++                <td>Powerful rights remain active without clear ownership.</td>
++                <td>Confirm the current need, remove obsolete assignments and document approved technical users.</td>
++                <td>High</td>
++              </tr>
++              <tr>
++                <td>Backups are scheduled, but the restore process has not been tested recently.</td>
++                <td>Recovery expectations may be incorrect during an incident.</td>
++                <td>Document backup coverage and perform a restore validation on a test environment.</td>
++                <td>Medium</td>
++              </tr>
++            </tbody>
++          </table>
++
            <p>
              The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
              understand the access model, critical features are documented and future upgrades can be planned with
@@ -226,6 +226,24 @@
              fewer surprises.
            </p>
++          <h2 id="readiness-checklist">XWiki security review readiness checklist</h2>
++
++          <p>
++            Before starting a security review, prepare the following information. This makes the review faster and helps
++            identify risks more clearly.
++          </p>
++
++          <ul class="resource-checklist">
++            <li>Current XWiki version and target upgrade version, if an upgrade is planned.</li>
++            <li>List of installed extensions and known custom applications.</li>
++            <li>Authentication method: local users, LDAP, OIDC, SAML, SSO or MFA.</li>
++            <li>Known restricted spaces, confidential areas or public-facing pages.</li>
++            <li>List of technical administrators and users with powerful rights.</li>
++            <li>Known custom scripts, templates, macros, UI extensions or Java components.</li>
++            <li>Backup location, frequency and last restore test, if known.</li>
++            <li>Staging or test environment availability.</li>
++          </ul>
++
            <h2 id="when-to-review">When should an XWiki security review be done?</h2>
            <p>
@@ -260,39 +260,49 @@
            <h2 id="security-review-faq">XWiki security review FAQ</h2>
--          <h3>What should an XWiki security review include?</h3>
--          <p>
--            An XWiki security review should include the installed XWiki version, upgrade path,
--            access rights, groups, authentication setup, installed extensions, custom code,
--            infrastructure, backups, restore expectations and operational procedures.
--          </p>
++          <details class="resource-faq-item" open>
++            <summary>What should an XWiki security review include?</summary>
++            <p>
++              An XWiki security review should include the installed XWiki version, upgrade path,
++              access rights, groups, authentication setup, installed extensions, custom code,
++              infrastructure, backups, restore expectations and operational procedures.
++            </p>
++          </details>
--          <h3>Is an updated XWiki instance automatically secure?</h3>
--          <p>
--            No. Updating XWiki is important, but security also depends on permissions,
--            authentication, extensions, custom code, infrastructure configuration, backups
--            and how the instance is maintained.
--          </p>
++          <details class="resource-faq-item">
++            <summary>Is an updated XWiki instance automatically secure?</summary>
++            <p>
++              No. Updating XWiki is important, but security also depends on permissions,
++              authentication, extensions, custom code, infrastructure configuration, backups
++              and how the instance is maintained.
++            </p>
++          </details>
--          <h3>Does SSO solve XWiki access control?</h3>
--          <p>
--            No. SSO helps authenticate users, but access control still depends on XWiki groups,
--            inherited permissions, page-level rights and administrative privileges.
--          </p>
++          <details class="resource-faq-item">
++            <summary>Does SSO solve XWiki access control?</summary>
++            <p>
++              No. SSO helps authenticate users, but access control still depends on XWiki groups,
++              inherited permissions, page-level rights and administrative privileges.
++            </p>
++          </details>
--          <h3>Why should custom code be reviewed?</h3>
--          <p>
--            Custom scripts, templates, macros, UI extensions and Java components can affect
--            permissions, workflows, rendering, integrations and upgrade behavior. They should
--            be identified, documented and tested.
--          </p>
++          <details class="resource-faq-item">
++            <summary>Why should custom code be reviewed?</summary>
++            <p>
++              Custom scripts, templates, macros, UI extensions and Java components can affect
++              permissions, workflows, rendering, integrations and upgrade behavior. They should
++              be identified, documented and tested.
++            </p>
++          </details>
--          <h3>When should an XWiki security review be done?</h3>
--          <p>
--            A review is useful before a major upgrade, after years of organic growth, after
--            authentication changes, before exposing the wiki more broadly, or when the instance
--            becomes business-critical.
--          </p>
++          <details class="resource-faq-item">
++            <summary>When should an XWiki security review be done?</summary>
++            <p>
++              A review is useful before a major upgrade, after years of organic growth, after
++              authentication changes, before exposing the wiki more broadly, or when the instance
++              becomes business-critical.
++            </p>
++          </details>
            <div class="resource-note related-resources">
              <p><strong>Related resources:</strong></p>