Skip to Content
Version 3.9 by Agnease on 2026/06/08 18:27
Show last authors
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 <li><a href="#security-review-faq">FAQ</a></li>
36 </ul>
37 </aside>
38
39 <article class="resource-content">
40
41 <p>
42 Many XWiki instances continue to work well from a user perspective while slowly accumulating security
43 and governance risks. Users can still log in, search, edit pages and access documents, but that does not
44 always mean the instance is properly secured or easy to maintain.
45 </p>
46
47 <p>
48 An XWiki security review is a practical audit of the platform configuration, access model,
49 authentication setup, installed extensions, custom code, infrastructure and recovery procedures.
50 </p>
51
52 <p>
53 Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
54 forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
55 weak fallback access or backup assumptions that were never tested.
56 </p>
57
58 <div class="resource-note">
59 <p>
60 <strong>In practice:</strong> an XWiki security review should evaluate the XWiki version,
61 access rights, authentication setup, installed extensions, custom code, infrastructure,
62 backups, restore expectations and the operational practices used to maintain the instance.
63 </p>
64 </div>
65
66 <p>
67 An XWiki security review is a structured assessment of the wiki platform, its configuration,
68 access model, authentication mechanisms, extensions, customizations and operational setup.
69 The goal is to identify risks, maintenance weaknesses and upgrade blockers before they affect
70 users or business-critical content.
71 </p>
72
73 <div class="resource-note">
74 <p>
75 <strong>The main point:</strong> an XWiki security review should not only check whether the application
76 is online. It should evaluate the platform, the access model and the operational practices around it.
77 </p>
78 </div>
79
80 <h2 id="why-it-matters">Why an XWiki security review matters</h2>
81
82 <p>
83 XWiki is often used as an internal knowledge base, intranet, documentation platform or controlled
84 document system. In these cases, the platform may contain sensitive procedures, internal decisions,
85 customer information, technical documentation, compliance records or business-critical workflows.
86 </p>
87
88 <p>
89 The more important the content becomes, the more important it is to understand who can access it, who can
90 change it, which customizations influence it and how safely the instance can be upgraded or restored.
91 </p>
92
93 <p>
94 A security review helps identify risks before they become incidents, upgrade blockers or maintenance
95 surprises. It also gives administrators a clearer view of the current state of the instance.
96 </p>
97
98 <h2 id="what-to-review">What should be reviewed</h2>
99
100 <h3>1. Version and upgrade status</h3>
101 <p>
102 The current XWiki version should be reviewed together with the target upgrade path, installed extensions
103 and infrastructure dependencies. An outdated instance is not only a maintenance concern. It can also mean
104 that security fixes, compatibility improvements and platform hardening are missing.
105 </p>
106
107 <p>
108 The review should also check whether upgrades are performed regularly or only when something breaks.
109 A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
110 </p>
111
112 <p>
113 For more details on upgrade planning, see
114 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>.
115 </p>
116
117 <h3>2. Access rights and permission model</h3>
118 <p>
119 XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
120 should check who has administration rights, who has script or programming rights, whether rights are
121 assigned through groups, and whether page-level exceptions are still understandable.
122 </p>
123
124 <p>
125 It is also important to review inherited rights, public areas, restricted spaces, old groups, inactive
126 users and sensitive pages. Many permission problems do not come from one obvious mistake, but from years
127 of small exceptions that nobody reviewed later.
128 </p>
129
130 <p>
131 For a deeper look at this topic, see
132 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
133 For a practical starting point, see
134 <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">how to start an XWiki access-rights review</a>.
135 </p>
136
137 <h3>3. Authentication and identity management</h3>
138 <p>
139 Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
140 Directory, OIDC, SAML, SSO and MFA setups all need to be checked together with group synchronization,
141 fallback login options, local administrator accounts and recovery procedures.
142 </p>
143
144 <p>
145 SSO is useful, but it does not automatically guarantee a clean access model. Authentication confirms who
146 the user is. Authorization still depends on how XWiki groups and rights are configured.
147 </p>
148
149 <h3>4. Extensions and custom code</h3>
150 <p>
151 Installed extensions, custom applications, Velocity scripts, Groovy scripts, macros, sheets, templates,
152 UI extensions and Java components are all part of the security and maintenance surface of the instance.
153 </p>
154
155 <p>
156 A review should identify what is installed, what is customized, what is still used, what is documented and
157 what needs special validation during upgrades. Custom code should be tracked, explained and tested, not
158 discovered accidentally during an incident or a production upgrade.
159 </p>
160
161 <p>
162 Customizations should also be reviewed from a maintenance perspective. See
163 <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
164 </p>
165
166 <h3>5. Configuration, infrastructure and operations</h3>
167 <p>
168 The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
169 access, filesystem and attachment storage, mail configuration, PDF export services, logs, monitoring,
170 server access and separation between production and staging.
171 </p>
172
173 <p>
174 Backups should be reviewed together with restore expectations. A backup strategy is incomplete if nobody
175 knows what is included, how long recovery would take or whether the restore process has ever been tested.
176 </p>
177
178 <div class="resource-inline-cta">
179 <p>
180 <strong>Need a clearer view of your XWiki security posture?</strong>
181 A structured review can check versions, access rights, authentication,
182 extensions, custom code, infrastructure, backups and operational practices.
183 </p>
184 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
185 </div>
186
187 <h2 id="security-checklist">XWiki security review checklist</h2>
188
189 <p>
190 A practical XWiki security review should cover both application-level and operational risks.
191 The following checklist can be used as a starting point when reviewing a production instance.
192 </p>
193
194 <ul class="resource-checklist">
195 <li>Check the current XWiki version, target version and upgrade path.</li>
196 <li>Review installed extensions, outdated components and unsupported customizations.</li>
197 <li>Audit administrator, script and programming rights.</li>
198 <li>Review groups, inherited permissions and page-level exceptions.</li>
199 <li>Validate authentication, SSO, MFA, fallback access and administrator recovery options.</li>
200 <li>Identify custom scripts, templates, macros, UI extensions and Java components.</li>
201 <li>Review public, internal and restricted areas.</li>
202 <li>Check infrastructure, HTTPS, reverse proxy, database, filesystem and mail configuration.</li>
203 <li>Confirm backup coverage, restore expectations and rollback procedures.</li>
204 <li>Document findings and prioritize remediation actions.</li>
205 </ul>
206
207 <h2 id="review-output">What the review should produce</h2>
208
209 <p>
210 A useful security review should not only produce a list of detected problems. It should produce a practical action
211 plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
212 </p>
213
214 <p>
215 Some findings may require immediate action, such as exposed administration rights or unsafe fallback
216 access. Others may become planned improvements, such as cleaning old groups, documenting custom code,
217 reviewing extensions or preparing the next upgrade.
218 </p>
219
220 <div class="resource-note">
221 <p>
222 <strong>A useful review should separate findings by priority:</strong> immediate risks,
223 planned remediation, maintenance improvements and documentation gaps. This makes the result
224 easier to act on instead of producing a generic list of observations.
225 </p>
226 </div>
227
228 <p>
229 The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
230 understand the access model, critical features are documented and future upgrades can be planned with
231 fewer surprises.
232 </p>
233
234 <h2 id="when-to-review">When should an XWiki security review be done?</h2>
235
236 <p>
237 A review is especially useful before a major upgrade, after years of organic growth, after an authentication
238 change, before exposing the instance more broadly, after a migration, or when the wiki becomes more
239 business-critical than it was when first installed.
240 </p>
241
242 <p>
243 It is also useful when administration responsibilities change. A new team should not have to guess how
244 permissions, extensions, customizations and recovery procedures were configured years earlier.
245 </p>
246
247 <div class="resource-note related-resources">
248 <p><strong>Security review series:</strong></p>
249 <ul>
250 <li>
251 <a href="$xwiki.getURL('resources.xwiki-security-review')">What an XWiki security review should actually include</a>
252 </li>
253 <li>
254 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
255 </li>
256 <li>
257 <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
258 </li>
259 </ul>
260 <p>
261 Future topics will cover authentication and access control, script and programming rights,
262 backup validation, extension review and operational practices.
263 </p>
264 </div>
265
266 <h2 id="security-review-faq">XWiki security review FAQ</h2>
267
268 <details class="resource-faq-item" open>
269 <summary>What should an XWiki security review include?</summary>
270 <p>
271 An XWiki security review should include the installed XWiki version, upgrade path,
272 access rights, groups, authentication setup, installed extensions, custom code,
273 infrastructure, backups, restore expectations and operational procedures.
274 </p>
275 </details>
276
277 <details class="resource-faq-item">
278 <summary>Is an updated XWiki instance automatically secure?</summary>
279 <p>
280 No. Updating XWiki is important, but security also depends on permissions,
281 authentication, extensions, custom code, infrastructure configuration, backups
282 and how the instance is maintained.
283 </p>
284 </details>
285
286 <details class="resource-faq-item">
287 <summary>Does SSO solve XWiki access control?</summary>
288 <p>
289 No. SSO helps authenticate users, but access control still depends on XWiki groups,
290 inherited permissions, page-level rights and administrative privileges.
291 </p>
292 </details>
293
294 <details class="resource-faq-item">
295 <summary>Why should custom code be reviewed?</summary>
296 <p>
297 Custom scripts, templates, macros, UI extensions and Java components can affect
298 permissions, workflows, rendering, integrations and upgrade behavior. They should
299 be identified, documented and tested.
300 </p>
301 </details>
302
303 <details class="resource-faq-item">
304 <summary>When should an XWiki security review be done?</summary>
305 <p>
306 A review is useful before a major upgrade, after years of organic growth, after
307 authentication changes, before exposing the wiki more broadly, or when the instance
308 becomes business-critical.
309 </p>
310 </details>
311
312 <div class="resource-note related-resources">
313 <p><strong>Related resources:</strong></p>
314 <ul>
315 <li>
316 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
317 </li>
318 <li>
319 <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
320 </li>
321 <li>
322 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">Why regular XWiki upgrades matter</a>
323 </li>
324 <li>
325 <a href="$xwiki.getURL('resources.xwiki-custom-development')">How to keep XWiki custom development maintainable across upgrades</a>
326 </li>
327 </ul>
328 </div>
329
330 <div class="resource-cta">
331 <h3>Need an XWiki security review?</h3>
332 <p>
333 If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
334 SSO, extensions and business-critical workflows, a structured review can help identify risks and define
335 the safest next steps.
336 </p>
337 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
338 </div>
339
340 </article>
341
342 </div>
343 </div>
344 </section>
345
346 <script type="application/ld+json">
347 {
348 "@context": "https://schema.org",
349 "@type": "FAQPage",
350 "mainEntity": [
351 {
352 "@type": "Question",
353 "name": "What should an XWiki security review include?",
354 "acceptedAnswer": {
355 "@type": "Answer",
356 "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."
357 }
358 },
359 {
360 "@type": "Question",
361 "name": "Is an updated XWiki instance automatically secure?",
362 "acceptedAnswer": {
363 "@type": "Answer",
364 "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."
365 }
366 },
367 {
368 "@type": "Question",
369 "name": "Does SSO solve XWiki access control?",
370 "acceptedAnswer": {
371 "@type": "Answer",
372 "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges."
373 }
374 },
375 {
376 "@type": "Question",
377 "name": "Why should custom code be reviewed in XWiki?",
378 "acceptedAnswer": {
379 "@type": "Answer",
380 "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."
381 }
382 },
383 {
384 "@type": "Question",
385 "name": "When should an XWiki security review be done?",
386 "acceptedAnswer": {
387 "@type": "Answer",
388 "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."
389 }
390 }
391 ]
392 }
393 </script>
394
395 {{/html}}
396 {{/velocity}}