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 1.3 to 1.4 From 3.10 to 3.11

From version 1.4

edited by Agnease
on 2026/05/26 07:47

Change comment: There is no comment for this version

To version 3.10

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

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)
Attachments (0 modified, 1 added, 0 removed)
- xwiki-security-review.png
Objects (1 modified, 0 added, 0 removed)
- Agnease.Code.SEODetailsClass[0]

Details

Page properties

Content

@@ -32,6 +32,7 @@
              <li><a href="#security-checklist">Security checklist</a></li>
              <li><a href="#review-output">What the review should produce</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>
          </aside>
@@ -44,6 +44,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.
@@ -51,6 +51,21 @@
            <div class="resource-note">
              <p>
++              <strong>In practice:</strong> an XWiki security review should evaluate the XWiki version,
++              access rights, authentication setup, installed extensions, custom code, infrastructure,
++              backups, restore expectations and the operational practices used to maintain the instance.
++            </p>
++          </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.
++          </p>
++
++          <div class="resource-note">
++            <p>
                <strong>The main point:</strong> an XWiki security review should not only check whether the application
                is online. It should evaluate the platform, the access model and the operational practices around it.
              </p>
@@ -88,6 +88,11 @@
              A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
            </p>
++          <p>
++            For more details on upgrade planning, see
++            <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>.
++          </p>
++
            <h3>2. Access rights and permission model</h3>
            <p>
              XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
@@ -101,6 +101,13 @@
              of small exceptions that nobody reviewed later.
            </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
++            <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">how to start an XWiki access-rights review</a>.
++          </p>
++
            <h3>3. Authentication and identity management</h3>
            <p>
              Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
@@ -125,6 +125,11 @@
              discovered accidentally during an incident or a production upgrade.
            </p>
++          <p>
++            Customizations should also be reviewed from a maintenance perspective. See
++            <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
++          </p>
++
            <h3>5. Configuration, infrastructure and operations</h3>
            <p>
              The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
@@ -137,8 +137,22 @@
              knows what is included, how long recovery would take or whether the restore process has ever been tested.
            </p>
--          <h2 id="security-checklist">Practical XWiki security review checklist</h2>
++          <div class="resource-inline-cta">
++            <p>
++              <strong>Need a clearer view of your XWiki security posture?</strong>
++              A structured review can check versions, access rights, authentication,
++              extensions, custom code, infrastructure, backups and operational practices.
++            </p>
++            <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
++          </div>
++          <h2 id="security-checklist">XWiki security review checklist</h2>
++
++          <p>
++            A practical XWiki security review should cover both application-level and operational risks.
++            The following checklist can be used as a starting point when reviewing a production instance.
++          </p>
++
            <ul class="resource-checklist">
              <li>Check the current XWiki version, target version and upgrade path.</li>
              <li>Review installed extensions, outdated components and unsupported customizations.</li>
@@ -155,7 +155,7 @@
            <h2 id="review-output">What the review should produce</h2>
            <p>
--            A useful security review should not only produce a list of problems. It should produce a practical action
++            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>
@@ -165,6 +165,14 @@
              reviewing extensions or preparing the next upgrade.
            </p>
++          <div class="resource-note">
++            <p>
++              <strong>A useful review should separate findings by priority:</strong> immediate risks,
++              planned remediation, maintenance improvements and documentation gaps. This makes the result
++              easier to act on instead of producing a generic list of observations.
++            </p>
++          </div>
++
            <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
@@ -184,15 +184,89 @@
              permissions, extensions, customizations and recovery procedures were configured years earlier.
            </p>
--          <div class="resource-note">
++          <div class="resource-note related-resources">
++            <p><strong>Security review series:</strong></p>
++            <ul>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-security-review')">What an XWiki security review should actually include</a>
++              </li>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
++              </li>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
++              </li>
++            </ul>
              <p>
--              Related resources:
--              <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
--              and
--              <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
++              Future topics will cover authentication and access control, script and programming rights,
++              backup validation, extension review and operational practices.
              </p>
            </div>
++          <h2 id="security-review-faq">XWiki security review FAQ</h2>
++
++          <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>
++
++          <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>
++
++          <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>
++
++          <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>
++
++          <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>
++            <ul>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
++              </li>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
++              </li>
++              <li>
++                <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">Why regular XWiki upgrades matter</a>
++              </li>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-custom-development')">How to keep XWiki custom development maintainable across upgrades</a>
++              </li>
++            </ul>
++          </div>
++
            <div class="resource-cta">
              <h3>Need an XWiki security review?</h3>
              <p>
@@ -209,5 +209,54 @@
      </div>
    </section>
++  <script type="application/ld+json">
++  {
++    "@context": "https://schema.org",
++    "@type": "FAQPage",
++    "mainEntity": [
++      {
++        "@type": "Question",
++        "name": "What should an XWiki security review include?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "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."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Is an updated XWiki instance automatically secure?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "No. Updating XWiki is important, but security also depends on permissions, authentication, extensions, custom code, infrastructure configuration, backups and how the instance is maintained."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Does SSO solve XWiki access control?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Why should custom code be reviewed in XWiki?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "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."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "When should an XWiki security review be done?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "text": "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."
++        }
++      }
++    ]
++  }
++  </script>
++
  {{/html}}
  {{/velocity}}

xwiki-security-review.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.Admin

Size

...	...	@@ -1,0 +1,1 @@
	1	+1.3 MB

Content

Agnease.Code.SEODetailsClass[0]

metaTitle

@@ -1,1 +1,1 @@
--XWiki Security Review Checklist: What to Check and Why
++What an XWiki Security Review Should Actually Include | Agnease