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 version 3.12

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

Change comment: There is no comment for this version

To version 1.1

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

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Title

@@ -1,1 +1,1 @@
--What an XWiki Security Review Should Actually Include
++xwiki-security-review

Content

@@ -1,499 +1,0 @@
--{{velocity}}
--#set ($discard = $xwiki.ssx.use('PublicWebSite.WebHome'))
--{{html clean="false"}}
--
--  <section class="resource-header" aria-labelledby="hero-title">
--    <div class="container">
--      <div class="text-center">
--        <div class="hero-kicker">
--          <i class="fa fa-shield" aria-hidden="true"></i>
--          XWiki security review
--        </div>
--      </div>
--
--      <h1 id="hero-title">What an XWiki security review should actually include</h1>
--
--      <p class="resource-summary">
--        A working XWiki instance is not automatically a secure one. A proper review should look at versions,
--        access rights, authentication, extensions, custom code, infrastructure and operational practices.
--      </p>
--    </div>
--  </section>
--
--  <section class="resource-page">
--    <div class="container">
--      <div class="resource-layout">
--
--        <aside class="resource-sidebar" aria-label="Page summary">
--          <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>
--        </aside>
--
--        <article class="resource-content">
--
--          <p>
--            Many XWiki instances continue to work well from a user perspective while slowly accumulating security
--            and governance risks. Users can still log in, search, edit pages and access documents, but that does not
--            always mean the instance is properly secured or easy to maintain.
--          </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.
--          </p>
--
--          <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>
--            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">
--            <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>
--          </div>
--
--          <h2 id="why-it-matters">Why an XWiki security review matters</h2>
--
--          <p>
--            XWiki is often used as an internal knowledge base, intranet, documentation platform or controlled
--            document system. In these cases, the platform may contain sensitive procedures, internal decisions,
--            customer information, technical documentation, compliance records or business-critical workflows.
--          </p>
--
--          <p>
--            The more important the content becomes, the more important it is to understand who can access it, who can
--            change it, which customizations influence it and how safely the instance can be upgraded or restored.
--          </p>
--
--          <p>
--            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>
--          <p>
--            The current XWiki version should be reviewed together with the target upgrade path, installed extensions
--            and infrastructure dependencies. An outdated instance is not only a maintenance concern. It can also mean
--            that security fixes, compatibility improvements and platform hardening are missing.
--          </p>
--
--          <p>
--            The review should also check whether upgrades are performed regularly or only when something breaks.
--            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
--            should check who has administration rights, who has script or programming rights, whether rights are
--            assigned through groups, and whether page-level exceptions are still understandable.
--          </p>
--
--          <p>
--            It is also important to review inherited rights, public areas, restricted spaces, old groups, inactive
--            users and sensitive pages. Many permission problems do not come from one obvious mistake, but from years
--            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
--            Directory, OIDC, SAML, SSO and MFA setups all need to be checked together with group synchronization,
--            fallback login options, local administrator accounts and recovery procedures.
--          </p>
--
--          <p>
--            SSO is useful, but it does not automatically guarantee a clean access model. Authentication confirms who
--            the user is. Authorization still depends on how XWiki groups and rights are configured.
--          </p>
--
--          <h3>4. Extensions and custom code</h3>
--          <p>
--            Installed extensions, custom applications, Velocity scripts, Groovy scripts, macros, sheets, templates,
--            UI extensions and Java components are all part of the security and maintenance surface of the instance.
--          </p>
--
--          <p>
--            A review should identify what is installed, what is customized, what is still used, what is documented and
--            what needs special validation during upgrades. Custom code should be tracked, explained and tested, not
--            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
--            access, filesystem and attachment storage, mail configuration, PDF export services, logs, monitoring,
--            server access and separation between production and staging.
--          </p>
--
--          <p>
--            Backups should be reviewed together with restore expectations. A backup strategy is incomplete if nobody
--            knows what is included, how long recovery would take or whether the restore process has ever been tested.
--          </p>
--
--          <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-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>
--            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>
--            <li>Audit administrator, script and programming rights.</li>
--            <li>Review groups, inherited permissions and page-level exceptions.</li>
--            <li>Validate authentication, SSO, MFA, fallback access and administrator recovery options.</li>
--            <li>Identify custom scripts, templates, macros, UI extensions and Java components.</li>
--            <li>Review public, internal and restricted areas.</li>
--            <li>Check infrastructure, HTTPS, reverse proxy, database, filesystem and mail configuration.</li>
--            <li>Confirm backup coverage, restore expectations and rollback procedures.</li>
--            <li>Document findings and prioritize remediation actions.</li>
--          </ul>
--
--          <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.
--          </p>
--
--          <p>
--            Some findings may require immediate action, such as exposed administration rights or unsafe fallback
--            access. Others may become planned improvements, such as cleaning old groups, documenting custom code,
--            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>
--
--          <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
--            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>
--            A review is especially useful before a major upgrade, after years of organic growth, after an authentication
--            change, before exposing the instance more broadly, after a migration, or when the wiki becomes more
--            business-critical than it was when first installed.
--          </p>
--
--          <p>
--            It is also useful when administration responsibilities change. A new team should not have to guess how
--            permissions, extensions, customizations and recovery procedures were configured years earlier.
--          </p>
--
--          <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>
--              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>
--              If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
--              SSO, extensions and business-critical workflows, a structured review can help identify risks and define
--              the safest next steps.
--            </p>
--            <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
--          </div>
--
--        </article>
--
--      </div>
--    </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,1 +1,0 @@
1		-XWiki.Admin

Size

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

Content

Agnease.Code.SEODetailsClass[0]

metaDescription

...	...	@@ -1,1 +1,0 @@
1		-Learn what an XWiki security review should include: version status, access rights, authentication, extensions, custom code, infrastructure, backups and operational practices.

metaTitle

...	...	@@ -1,1 +1,0 @@
1		-What an XWiki Security Review Should Actually Include \| Agnease