Changes for page What an XWiki Security Review Should Actually Include

Last modified by Agnease on 2026/05/26 15:27

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

From 1.9 to 2.1

From version 1.1

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

Change comment: There is no comment for this version

To version 1.9

edited by Agnease
on 2026/05/26 10:48

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (2 modified, 0 added, 0 removed)
Objects (0 modified, 1 added, 0 removed)
- Agnease.Code.SEODetailsClass[0]

Details

Page properties

Title

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

Content

@@ -1,0 +1,346 @@
++{{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="#what-to-review">What to review</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="#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>
++            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>
++            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>
++          </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>
++            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.
++          </p>
++
++          <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>
++
++          <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>Not sure how risky your current XWiki version is?</strong>
++              A short technical review can clarify the upgrade path, extension compatibility,
++              custom code risks and validation needs before production is touched.
++            </p>
++            <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a quick 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>
++            <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>
++
++          <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="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>
++
++          <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>
++
++          <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>
++
++          <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>
++
++          <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>
++
++          <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>
++
++          <div class="resource-note">
++            <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>.
++            </p>
++          </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}}

Agnease.Code.SEODetailsClass[0]

metaDescription

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

metaTitle

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