Skip to Content
Last modified by Agnease on 2026/06/08 18:44
Hide last authors
Agnease 1.2 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>
Agnease 3.12 31 <li><a href="#quick-self-check">Quick self-check</a></li>
Agnease 1.2 32 <li><a href="#what-to-review">What to review</a></li>
Agnease 3.12 33 <li><a href="#common-findings">Common findings</a></li>
Agnease 1.2 34 <li><a href="#security-checklist">Security checklist</a></li>
35 <li><a href="#review-output">What the review should produce</a></li>
Agnease 3.12 36 <li><a href="#readiness-checklist">What to prepare</a></li>
Agnease 1.2 37 <li><a href="#when-to-review">When to run a review</a></li>
Agnease 1.8 38 <li><a href="#security-review-faq">FAQ</a></li>
Agnease 1.2 39 </ul>
40 </aside>
41
42 <article class="resource-content">
43
44 <p>
45 Many XWiki instances continue to work well from a user perspective while slowly accumulating security
46 and governance risks. Users can still log in, search, edit pages and access documents, but that does not
47 always mean the instance is properly secured or easy to maintain.
48 </p>
49
50 <p>
Agnease 3.9 51 An XWiki security review is a practical audit of the platform configuration, access model,
52 authentication setup, installed extensions, custom code, infrastructure and recovery procedures.
53 </p>
54
55 <p>
Agnease 1.2 56 Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
57 forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
58 weak fallback access or backup assumptions that were never tested.
59 </p>
60
61 <div class="resource-note">
62 <p>
Agnease 1.8 63 <strong>In practice:</strong> an XWiki security review should evaluate the XWiki version,
64 access rights, authentication setup, installed extensions, custom code, infrastructure,
65 backups, restore expectations and the operational practices used to maintain the instance.
66 </p>
67 </div>
68
69 <p>
Agnease 3.12 70 The value of the review is not only to find technical issues. It is to understand how the instance is actually
71 used, where risk has accumulated over time, and what should be cleaned up before the next upgrade, migration,
72 authentication change or business-critical rollout.
Agnease 1.8 73 </p>
74
75 <div class="resource-note">
76 <p>
Agnease 1.2 77 <strong>The main point:</strong> an XWiki security review should not only check whether the application
78 is online. It should evaluate the platform, the access model and the operational practices around it.
79 </p>
80 </div>
81
82 <h2 id="why-it-matters">Why an XWiki security review matters</h2>
83
84 <p>
85 XWiki is often used as an internal knowledge base, intranet, documentation platform or controlled
86 document system. In these cases, the platform may contain sensitive procedures, internal decisions,
87 customer information, technical documentation, compliance records or business-critical workflows.
88 </p>
89
90 <p>
91 The more important the content becomes, the more important it is to understand who can access it, who can
92 change it, which customizations influence it and how safely the instance can be upgraded or restored.
93 </p>
94
95 <p>
Agnease 3.12 96 In real XWiki instances, security problems are rarely caused by a single visible mistake. They often come from
97 years of small configuration decisions: one temporary group, one local right exception, one old extension, one
98 undocumented script, one backup procedure that nobody has tested recently.
Agnease 1.2 99 </p>
100
Agnease 3.12 101 <h2 id="quick-self-check">Quick self-check: does your XWiki need a security review?</h2>
102
103 <p>
104 Your XWiki instance may need a security review if one or more of these situations sound familiar.
105 </p>
106
107 <ul class="resource-checklist">
108 <li>You are not sure who currently has admin, script or programming rights.</li>
109 <li>The instance has not been upgraded regularly or the upgrade path is unclear.</li>
110 <li>SSO, LDAP, OIDC or SAML was configured years ago and not reviewed recently.</li>
111 <li>Custom scripts, templates, macros or extensions exist but are not clearly documented.</li>
112 <li>Groups and page-level rights have grown organically over several years.</li>
113 <li>Backups exist, but the restore process has not been tested or documented.</li>
114 <li>A new team inherited the instance and has to guess how rights, extensions or customizations were configured.</li>
115 </ul>
116
117 <div class="resource-note">
118 <p>
119 <strong>Practical signal:</strong> if the instance works but nobody can clearly explain the access model,
120 the customizations and the recovery process, the risk is not only technical. It is operational.
121 </p>
122 </div>
123
Agnease 1.2 124 <h2 id="what-to-review">What should be reviewed</h2>
125
126 <h3>1. Version and upgrade status</h3>
127 <p>
128 The current XWiki version should be reviewed together with the target upgrade path, installed extensions
129 and infrastructure dependencies. An outdated instance is not only a maintenance concern. It can also mean
130 that security fixes, compatibility improvements and platform hardening are missing.
131 </p>
132
133 <p>
134 The review should also check whether upgrades are performed regularly or only when something breaks.
135 A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
136 </p>
137
Agnease 1.8 138 <p>
139 For more details on upgrade planning, see
140 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>.
141 </p>
142
Agnease 1.2 143 <h3>2. Access rights and permission model</h3>
144 <p>
145 XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
146 should check who has administration rights, who has script or programming rights, whether rights are
147 assigned through groups, and whether page-level exceptions are still understandable.
148 </p>
149
150 <p>
151 It is also important to review inherited rights, public areas, restricted spaces, old groups, inactive
152 users and sensitive pages. Many permission problems do not come from one obvious mistake, but from years
153 of small exceptions that nobody reviewed later.
154 </p>
155
Agnease 3.9 156 <p>
Agnease 3.5 157 For a deeper look at this topic, see
158 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
159 For a practical starting point, see
160 <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">how to start an XWiki access-rights review</a>.
Agnease 3.2 161 </p>
162
Agnease 1.2 163 <h3>3. Authentication and identity management</h3>
164 <p>
165 Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
166 Directory, OIDC, SAML, SSO and MFA setups all need to be checked together with group synchronization,
167 fallback login options, local administrator accounts and recovery procedures.
168 </p>
169
170 <p>
171 SSO is useful, but it does not automatically guarantee a clean access model. Authentication confirms who
172 the user is. Authorization still depends on how XWiki groups and rights are configured.
173 </p>
174
175 <h3>4. Extensions and custom code</h3>
176 <p>
177 Installed extensions, custom applications, Velocity scripts, Groovy scripts, macros, sheets, templates,
178 UI extensions and Java components are all part of the security and maintenance surface of the instance.
179 </p>
180
181 <p>
182 A review should identify what is installed, what is customized, what is still used, what is documented and
183 what needs special validation during upgrades. Custom code should be tracked, explained and tested, not
184 discovered accidentally during an incident or a production upgrade.
185 </p>
186
Agnease 1.8 187 <p>
188 Customizations should also be reviewed from a maintenance perspective. See
189 <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
190 </p>
191
Agnease 1.2 192 <h3>5. Configuration, infrastructure and operations</h3>
193 <p>
194 The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
195 access, filesystem and attachment storage, mail configuration, PDF export services, logs, monitoring,
196 server access and separation between production and staging.
197 </p>
198
199 <p>
200 Backups should be reviewed together with restore expectations. A backup strategy is incomplete if nobody
201 knows what is included, how long recovery would take or whether the restore process has ever been tested.
202 </p>
203
Agnease 1.9 204 <div class="resource-inline-cta">
205 <p>
Agnease 2.1 206 <strong>Need a clearer view of your XWiki security posture?</strong>
207 A structured review can check versions, access rights, authentication,
208 extensions, custom code, infrastructure, backups and operational practices.
Agnease 1.9 209 </p>
Agnease 3.11 210 <a class="btn btn-default" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
Agnease 1.9 211 </div>
212
Agnease 3.12 213 <h2 id="common-findings">Common findings in real XWiki security reviews</h2>
214
215 <p>
216 In real XWiki instances, security risks are often not caused by one major mistake. They usually come from
217 configuration decisions that were reasonable at the time but were never reviewed together later.
218 </p>
219
220 <ul class="resource-checklist">
221 <li>Old administrator accounts that are still active.</li>
222 <li>Script or programming rights granted to users who no longer maintain the platform.</li>
223 <li>Groups created for old projects that still grant access.</li>
224 <li>Page-level rights added as exceptions and never documented.</li>
225 <li>Custom Velocity or Groovy code that is business-critical but undocumented.</li>
226 <li>Extensions installed years ago without a clear owner or upgrade validation process.</li>
227 <li>SSO configured correctly for login, but not reviewed together with XWiki groups.</li>
228 <li>Backup jobs scheduled automatically, but restore expectations never tested.</li>
229 <li>Production changes performed without a staging or rollback habit.</li>
230 </ul>
231
232 <h2 id="what-this-is-not">What this review is not</h2>
233
234 <p>
235 A security review is not a one-click scan and it is not limited to checking the installed XWiki version.
236 Automated checks can help, but they cannot fully explain why a group has access, whether a custom script is still
237 needed, or whether a restore procedure would actually work during an incident.
238 </p>
239
240 <p>
241 The review should combine technical checks with context: how the wiki is used, which areas are sensitive, which
242 users administer it, what customizations matter and what the organization expects during an incident or upgrade.
243 </p>
244
Agnease 1.8 245 <h2 id="security-checklist">XWiki security review checklist</h2>
Agnease 1.2 246
Agnease 1.8 247 <p>
248 A practical XWiki security review should cover both application-level and operational risks.
249 The following checklist can be used as a starting point when reviewing a production instance.
250 </p>
251
Agnease 1.2 252 <ul class="resource-checklist">
253 <li>Check the current XWiki version, target version and upgrade path.</li>
254 <li>Review installed extensions, outdated components and unsupported customizations.</li>
255 <li>Audit administrator, script and programming rights.</li>
256 <li>Review groups, inherited permissions and page-level exceptions.</li>
257 <li>Validate authentication, SSO, MFA, fallback access and administrator recovery options.</li>
258 <li>Identify custom scripts, templates, macros, UI extensions and Java components.</li>
259 <li>Review public, internal and restricted areas.</li>
260 <li>Check infrastructure, HTTPS, reverse proxy, database, filesystem and mail configuration.</li>
261 <li>Confirm backup coverage, restore expectations and rollback procedures.</li>
262 <li>Document findings and prioritize remediation actions.</li>
263 </ul>
264
265 <h2 id="review-output">What the review should produce</h2>
266
267 <p>
Agnease 3.12 268 A useful security review should not only produce a list of detected problems. It should produce a practical
269 action plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
Agnease 1.2 270 </p>
271
272 <p>
273 Some findings may require immediate action, such as exposed administration rights or unsafe fallback
274 access. Others may become planned improvements, such as cleaning old groups, documenting custom code,
275 reviewing extensions or preparing the next upgrade.
276 </p>
277
Agnease 1.8 278 <div class="resource-note">
279 <p>
280 <strong>A useful review should separate findings by priority:</strong> immediate risks,
281 planned remediation, maintenance improvements and documentation gaps. This makes the result
282 easier to act on instead of producing a generic list of observations.
283 </p>
284 </div>
285
Agnease 3.12 286 <h3>Example review finding</h3>
287
288 <table class="table table-bordered table-striped">
289 <thead>
290 <tr>
291 <th>Finding</th>
292 <th>Risk</th>
293 <th>Recommended action</th>
294 <th>Priority</th>
295 </tr>
296 </thead>
297 <tbody>
298 <tr>
299 <td>Several users have script rights but are no longer responsible for XWiki administration.</td>
300 <td>Powerful rights remain active without clear ownership.</td>
301 <td>Confirm the current need, remove obsolete assignments and document approved technical users.</td>
302 <td>High</td>
303 </tr>
304 <tr>
305 <td>Backups are scheduled, but the restore process has not been tested recently.</td>
306 <td>Recovery expectations may be incorrect during an incident.</td>
307 <td>Document backup coverage and perform a restore validation on a test environment.</td>
308 <td>Medium</td>
309 </tr>
310 </tbody>
311 </table>
312
Agnease 1.2 313 <p>
314 The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
315 understand the access model, critical features are documented and future upgrades can be planned with
316 fewer surprises.
317 </p>
318
Agnease 3.12 319 <h2 id="readiness-checklist">XWiki security review readiness checklist</h2>
320
321 <p>
322 Before starting a security review, prepare the following information. This makes the review faster and helps
323 identify risks more clearly.
324 </p>
325
326 <ul class="resource-checklist">
327 <li>Current XWiki version and target upgrade version, if an upgrade is planned.</li>
328 <li>List of installed extensions and known custom applications.</li>
329 <li>Authentication method: local users, LDAP, OIDC, SAML, SSO or MFA.</li>
330 <li>Known restricted spaces, confidential areas or public-facing pages.</li>
331 <li>List of technical administrators and users with powerful rights.</li>
332 <li>Known custom scripts, templates, macros, UI extensions or Java components.</li>
333 <li>Backup location, frequency and last restore test, if known.</li>
334 <li>Staging or test environment availability.</li>
335 </ul>
336
Agnease 1.2 337 <h2 id="when-to-review">When should an XWiki security review be done?</h2>
338
339 <p>
340 A review is especially useful before a major upgrade, after years of organic growth, after an authentication
341 change, before exposing the instance more broadly, after a migration, or when the wiki becomes more
342 business-critical than it was when first installed.
343 </p>
344
345 <p>
346 It is also useful when administration responsibilities change. A new team should not have to guess how
347 permissions, extensions, customizations and recovery procedures were configured years earlier.
348 </p>
349
Agnease 3.8 350 <div class="resource-note related-resources">
351 <p><strong>Security review series:</strong></p>
352 <ul>
353 <li>
354 <a href="$xwiki.getURL('resources.xwiki-security-review')">What an XWiki security review should actually include</a>
355 </li>
356 <li>
357 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
358 </li>
359 <li>
360 <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
361 </li>
362 </ul>
Agnease 3.3 363 <p>
Agnease 3.8 364 Future topics will cover authentication and access control, script and programming rights,
365 backup validation, extension review and operational practices.
Agnease 3.3 366 </p>
367 </div>
368
Agnease 1.8 369 <h2 id="security-review-faq">XWiki security review FAQ</h2>
370
Agnease 3.9 371 <details class="resource-faq-item" open>
372 <summary>What should an XWiki security review include?</summary>
373 <p>
374 An XWiki security review should include the installed XWiki version, upgrade path,
375 access rights, groups, authentication setup, installed extensions, custom code,
376 infrastructure, backups, restore expectations and operational procedures.
377 </p>
378 </details>
Agnease 1.8 379
Agnease 3.9 380 <details class="resource-faq-item">
381 <summary>Is an updated XWiki instance automatically secure?</summary>
382 <p>
383 No. Updating XWiki is important, but security also depends on permissions,
384 authentication, extensions, custom code, infrastructure configuration, backups
385 and how the instance is maintained.
386 </p>
387 </details>
Agnease 1.8 388
Agnease 3.9 389 <details class="resource-faq-item">
390 <summary>Does SSO solve XWiki access control?</summary>
391 <p>
392 No. SSO helps authenticate users, but access control still depends on XWiki groups,
393 inherited permissions, page-level rights and administrative privileges.
394 </p>
395 </details>
Agnease 1.8 396
Agnease 3.9 397 <details class="resource-faq-item">
398 <summary>Why should custom code be reviewed?</summary>
399 <p>
400 Custom scripts, templates, macros, UI extensions and Java components can affect
401 permissions, workflows, rendering, integrations and upgrade behavior. They should
402 be identified, documented and tested.
403 </p>
404 </details>
Agnease 1.8 405
Agnease 3.9 406 <details class="resource-faq-item">
407 <summary>When should an XWiki security review be done?</summary>
408 <p>
409 A review is useful before a major upgrade, after years of organic growth, after
410 authentication changes, before exposing the wiki more broadly, or when the instance
411 becomes business-critical.
412 </p>
413 </details>
Agnease 1.8 414
Agnease 3.7 415 <div class="resource-note related-resources">
416 <p><strong>Related resources:</strong></p>
417 <ul>
418 <li>
419 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
420 </li>
421 <li>
422 <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
423 </li>
424 <li>
425 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">Why regular XWiki upgrades matter</a>
426 </li>
427 <li>
428 <a href="$xwiki.getURL('resources.xwiki-custom-development')">How to keep XWiki custom development maintainable across upgrades</a>
429 </li>
430 </ul>
Agnease 1.2 431 </div>
432
433 <div class="resource-cta">
434 <h3>Need an XWiki security review?</h3>
435 <p>
436 If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
437 SSO, extensions and business-critical workflows, a structured review can help identify risks and define
438 the safest next steps.
439 </p>
440 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
441 </div>
442
443 </article>
444
445 </div>
446 </div>
447 </section>
448
Agnease 1.8 449 <script type="application/ld+json">
450 {
451 "@context": "https://schema.org",
452 "@type": "FAQPage",
453 "mainEntity": [
454 {
455 "@type": "Question",
456 "name": "What should an XWiki security review include?",
457 "acceptedAnswer": {
458 "@type": "Answer",
459 "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."
460 }
461 },
462 {
463 "@type": "Question",
464 "name": "Is an updated XWiki instance automatically secure?",
465 "acceptedAnswer": {
466 "@type": "Answer",
467 "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."
468 }
469 },
470 {
471 "@type": "Question",
472 "name": "Does SSO solve XWiki access control?",
473 "acceptedAnswer": {
474 "@type": "Answer",
475 "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges."
476 }
477 },
478 {
479 "@type": "Question",
480 "name": "Why should custom code be reviewed in XWiki?",
481 "acceptedAnswer": {
482 "@type": "Answer",
483 "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."
484 }
485 },
486 {
487 "@type": "Question",
488 "name": "When should an XWiki security review be done?",
489 "acceptedAnswer": {
490 "@type": "Answer",
491 "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."
492 }
493 }
494 ]
495 }
496 </script>
497
Agnease 1.2 498 {{/html}}
499 {{/velocity}}