Skip to Content
Last modified by Agnease on 2026/05/26 15:27
From version 1.5
edited by Agnease
on 2026/05/26 07:48
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

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -What an XWiki Security Review Should Actually Include
1 +xwiki-security-review
Content
... ... @@ -1,213 +1,0 @@
1 -{{velocity}}
2 -#set ($discard = $xwiki.ssx.use('PublicWebSite.WebHome'))
3 -{{html clean="false"}}
4 -
5 - <section class="resource-header" aria-labelledby="hero-title">
6 - <div class="container">
7 - <div class="text-center">
8 - <div class="hero-kicker">
9 - <i class="fa fa-shield" aria-hidden="true"></i>
10 - XWiki security review
11 - </div>
12 - </div>
13 -
14 - <h1 id="hero-title">What an XWiki security review should actually include</h1>
15 -
16 - <p class="resource-summary">
17 - A working XWiki instance is not automatically a secure one. A proper review should look at versions,
18 - access rights, authentication, extensions, custom code, infrastructure and operational practices.
19 - </p>
20 - </div>
21 - </section>
22 -
23 - <section class="resource-page">
24 - <div class="container">
25 - <div class="resource-layout">
26 -
27 - <aside class="resource-sidebar" aria-label="Page summary">
28 - <h4>In this guide</h4>
29 - <ul>
30 - <li><a href="#why-it-matters">Why it matters</a></li>
31 - <li><a href="#what-to-review">What to review</a></li>
32 - <li><a href="#security-checklist">Security checklist</a></li>
33 - <li><a href="#review-output">What the review should produce</a></li>
34 - <li><a href="#when-to-review">When to run a review</a></li>
35 - </ul>
36 - </aside>
37 -
38 - <article class="resource-content">
39 -
40 - <p>
41 - Many XWiki instances continue to work well from a user perspective while slowly accumulating security
42 - and governance risks. Users can still log in, search, edit pages and access documents, but that does not
43 - always mean the instance is properly secured or easy to maintain.
44 - </p>
45 -
46 - <p>
47 - Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
48 - forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
49 - weak fallback access or backup assumptions that were never tested.
50 - </p>
51 -
52 - <div class="resource-note">
53 - <p>
54 - <strong>The main point:</strong> an XWiki security review should not only check whether the application
55 - is online. It should evaluate the platform, the access model and the operational practices around it.
56 - </p>
57 - </div>
58 -
59 - <h2 id="why-it-matters">Why an XWiki security review matters</h2>
60 -
61 - <p>
62 - XWiki is often used as an internal knowledge base, intranet, documentation platform or controlled
63 - document system. In these cases, the platform may contain sensitive procedures, internal decisions,
64 - customer information, technical documentation, compliance records or business-critical workflows.
65 - </p>
66 -
67 - <p>
68 - The more important the content becomes, the more important it is to understand who can access it, who can
69 - change it, which customizations influence it and how safely the instance can be upgraded or restored.
70 - </p>
71 -
72 - <p>
73 - A security review helps identify risks before they become incidents, upgrade blockers or maintenance
74 - surprises. It also gives administrators a clearer view of the current state of the instance.
75 - </p>
76 -
77 - <h2 id="what-to-review">What should be reviewed</h2>
78 -
79 - <h3>1. Version and upgrade status</h3>
80 - <p>
81 - The current XWiki version should be reviewed together with the target upgrade path, installed extensions
82 - and infrastructure dependencies. An outdated instance is not only a maintenance concern. It can also mean
83 - that security fixes, compatibility improvements and platform hardening are missing.
84 - </p>
85 -
86 - <p>
87 - The review should also check whether upgrades are performed regularly or only when something breaks.
88 - A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
89 - </p>
90 -
91 - <h3>2. Access rights and permission model</h3>
92 - <p>
93 - XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
94 - should check who has administration rights, who has script or programming rights, whether rights are
95 - assigned through groups, and whether page-level exceptions are still understandable.
96 - </p>
97 -
98 - <p>
99 - It is also important to review inherited rights, public areas, restricted spaces, old groups, inactive
100 - users and sensitive pages. Many permission problems do not come from one obvious mistake, but from years
101 - of small exceptions that nobody reviewed later.
102 - </p>
103 -
104 - <h3>3. Authentication and identity management</h3>
105 - <p>
106 - Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
107 - Directory, OIDC, SAML, SSO and MFA setups all need to be checked together with group synchronization,
108 - fallback login options, local administrator accounts and recovery procedures.
109 - </p>
110 -
111 - <p>
112 - SSO is useful, but it does not automatically guarantee a clean access model. Authentication confirms who
113 - the user is. Authorization still depends on how XWiki groups and rights are configured.
114 - </p>
115 -
116 - <h3>4. Extensions and custom code</h3>
117 - <p>
118 - Installed extensions, custom applications, Velocity scripts, Groovy scripts, macros, sheets, templates,
119 - UI extensions and Java components are all part of the security and maintenance surface of the instance.
120 - </p>
121 -
122 - <p>
123 - A review should identify what is installed, what is customized, what is still used, what is documented and
124 - what needs special validation during upgrades. Custom code should be tracked, explained and tested, not
125 - discovered accidentally during an incident or a production upgrade.
126 - </p>
127 -
128 - <h3>5. Configuration, infrastructure and operations</h3>
129 - <p>
130 - The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
131 - access, filesystem and attachment storage, mail configuration, PDF export services, logs, monitoring,
132 - server access and separation between production and staging.
133 - </p>
134 -
135 - <p>
136 - Backups should be reviewed together with restore expectations. A backup strategy is incomplete if nobody
137 - knows what is included, how long recovery would take or whether the restore process has ever been tested.
138 - </p>
139 -
140 - <h2 id="security-checklist">Practical XWiki security review checklist</h2>
141 -
142 - <ul class="resource-checklist">
143 - <li>Check the current XWiki version, target version and upgrade path.</li>
144 - <li>Review installed extensions, outdated components and unsupported customizations.</li>
145 - <li>Audit administrator, script and programming rights.</li>
146 - <li>Review groups, inherited permissions and page-level exceptions.</li>
147 - <li>Validate authentication, SSO, MFA, fallback access and administrator recovery options.</li>
148 - <li>Identify custom scripts, templates, macros, UI extensions and Java components.</li>
149 - <li>Review public, internal and restricted areas.</li>
150 - <li>Check infrastructure, HTTPS, reverse proxy, database, filesystem and mail configuration.</li>
151 - <li>Confirm backup coverage, restore expectations and rollback procedures.</li>
152 - <li>Document findings and prioritize remediation actions.</li>
153 - </ul>
154 -
155 - <h2 id="review-output">What the review should produce</h2>
156 -
157 - <p>
158 - A useful security review should not only produce a list of problems. It should produce a practical action
159 - plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
160 - </p>
161 -
162 - <p>
163 - Some findings may require immediate action, such as exposed administration rights or unsafe fallback
164 - access. Others may become planned improvements, such as cleaning old groups, documenting custom code,
165 - reviewing extensions or preparing the next upgrade.
166 - </p>
167 -
168 - <p>
169 - The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
170 - understand the access model, critical features are documented and future upgrades can be planned with
171 - fewer surprises.
172 - </p>
173 -
174 - <h2 id="when-to-review">When should an XWiki security review be done?</h2>
175 -
176 - <p>
177 - A review is especially useful before a major upgrade, after years of organic growth, after an authentication
178 - change, before exposing the instance more broadly, after a migration, or when the wiki becomes more
179 - business-critical than it was when first installed.
180 - </p>
181 -
182 - <p>
183 - It is also useful when administration responsibilities change. A new team should not have to guess how
184 - permissions, extensions, customizations and recovery procedures were configured years earlier.
185 - </p>
186 -
187 - <div class="resource-note">
188 - <p>
189 - Related resources:
190 - <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
191 - and
192 - <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
193 - </p>
194 - </div>
195 -
196 - <div class="resource-cta">
197 - <h3>Need an XWiki security review?</h3>
198 - <p>
199 - If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
200 - SSO, extensions and business-critical workflows, a structured review can help identify risks and define
201 - the safest next steps.
202 - </p>
203 - <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
204 - </div>
205 -
206 - </article>
207 -
208 - </div>
209 - </div>
210 - </section>
211 -
212 -{{/html}}
213 -{{/velocity}}
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