Skip to Content
Last modified by Alex Cotiuga on 2026/07/13 06:44
From version 3.5
edited by Alex Cotiuga
on 2026/06/08 18:16
Change comment: There is no comment for this version
To version 4.5
edited by Alex Cotiuga
on 2026/07/13 06:44
Change comment: There is no comment for this version

Summary

Details

Page properties
Default language
... ... @@ -1,1 +1,0 @@
1 -en
Hidden
... ... @@ -1,1 +1,1 @@
1 -false
1 +true
Content
... ... @@ -28,9 +28,12 @@
28 28   <h4>In this guide</h4>
29 29   <ul>
30 30   <li><a href="#why-it-matters">Why it matters</a></li>
31 + <li><a href="#quick-self-check">Quick self-check</a></li>
31 31   <li><a href="#what-to-review">What to review</a></li>
33 + <li><a href="#common-findings">Common findings</a></li>
32 32   <li><a href="#security-checklist">Security checklist</a></li>
33 33   <li><a href="#review-output">What the review should produce</a></li>
36 + <li><a href="#readiness-checklist">What to prepare</a></li>
34 34   <li><a href="#when-to-review">When to run a review</a></li>
35 35   <li><a href="#security-review-faq">FAQ</a></li>
36 36   </ul>
... ... @@ -45,6 +45,11 @@
45 45   </p>
46 46  
47 47   <p>
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>
48 48   Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
49 49   forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
50 50   weak fallback access or backup assumptions that were never tested.
... ... @@ -59,10 +59,9 @@
59 59   </div>
60 60  
61 61   <p>
62 - An XWiki security review is a structured assessment of the wiki platform, its configuration,
63 - access model, authentication mechanisms, extensions, customizations and operational setup.
64 - The goal is to identify risks, maintenance weaknesses and upgrade blockers before they affect
65 - users or business-critical content.
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.
66 66   </p>
67 67  
68 68   <div class="resource-note">
... ... @@ -86,10 +86,34 @@
86 86   </p>
87 87  
88 88   <p>
89 - A security review helps identify risks before they become incidents, upgrade blockers or maintenance
90 - surprises. It also gives administrators a clearer view of the current state of the instance.
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.
91 91   </p>
92 92  
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 +
93 93   <h2 id="what-to-review">What should be reviewed</h2>
94 94  
95 95   <h3>1. Version and upgrade status</h3>
... ... @@ -122,7 +122,7 @@
122 122   of small exceptions that nobody reviewed later.
123 123   </p>
124 124  
125 - <p>
156 + <p>
126 126   For a deeper look at this topic, see
127 127   <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
128 128   For a practical starting point, see
... ... @@ -176,9 +176,42 @@
176 176   A structured review can check versions, access rights, authentication,
177 177   extensions, custom code, infrastructure, backups and operational practices.
178 178   </p>
179 - <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
210 + <a class="btn btn-default" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
211 + <a class="btn btn-secondary" href="$xwiki.getURL('pricing.WebHome')#common-packages">View review pricing</a>
180 180   </div>
181 181  
214 + <h2 id="common-findings">Common findings in real XWiki security reviews</h2>
215 +
216 + <p>
217 + In real XWiki instances, security risks are often not caused by one major mistake. They usually come from
218 + configuration decisions that were reasonable at the time but were never reviewed together later.
219 + </p>
220 +
221 + <ul class="resource-checklist">
222 + <li>Old administrator accounts that are still active.</li>
223 + <li>Script or programming rights granted to users who no longer maintain the platform.</li>
224 + <li>Groups created for old projects that still grant access.</li>
225 + <li>Page-level rights added as exceptions and never documented.</li>
226 + <li>Custom Velocity or Groovy code that is business-critical but undocumented.</li>
227 + <li>Extensions installed years ago without a clear owner or upgrade validation process.</li>
228 + <li>SSO configured correctly for login, but not reviewed together with XWiki groups.</li>
229 + <li>Backup jobs scheduled automatically, but restore expectations never tested.</li>
230 + <li>Production changes performed without a staging or rollback habit.</li>
231 + </ul>
232 +
233 + <h2 id="what-this-is-not">What this review is not</h2>
234 +
235 + <p>
236 + A security review is not a one-click scan and it is not limited to checking the installed XWiki version.
237 + Automated checks can help, but they cannot fully explain why a group has access, whether a custom script is still
238 + needed, or whether a restore procedure would actually work during an incident.
239 + </p>
240 +
241 + <p>
242 + The review should combine technical checks with context: how the wiki is used, which areas are sensitive, which
243 + users administer it, what customizations matter and what the organization expects during an incident or upgrade.
244 + </p>
245 +
182 182   <h2 id="security-checklist">XWiki security review checklist</h2>
183 183  
184 184   <p>
... ... @@ -202,8 +202,8 @@
202 202   <h2 id="review-output">What the review should produce</h2>
203 203  
204 204   <p>
205 - A useful security review should not only produce a list of detected problems. It should produce a practical action
206 - plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
269 + A useful security review should not only produce a list of detected problems. It should produce a practical
270 + action plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
207 207   </p>
208 208  
209 209   <p>
... ... @@ -220,6 +220,33 @@
220 220   </p>
221 221   </div>
222 222  
287 + <h3>Example review finding</h3>
288 +
289 + <table class="table table-bordered table-striped">
290 + <thead>
291 + <tr>
292 + <th>Finding</th>
293 + <th>Risk</th>
294 + <th>Recommended action</th>
295 + <th>Priority</th>
296 + </tr>
297 + </thead>
298 + <tbody>
299 + <tr>
300 + <td>Several users have script rights but are no longer responsible for XWiki administration.</td>
301 + <td>Powerful rights remain active without clear ownership.</td>
302 + <td>Confirm the current need, remove obsolete assignments and document approved technical users.</td>
303 + <td>High</td>
304 + </tr>
305 + <tr>
306 + <td>Backups are scheduled, but the restore process has not been tested recently.</td>
307 + <td>Recovery expectations may be incorrect during an incident.</td>
308 + <td>Document backup coverage and perform a restore validation on a test environment.</td>
309 + <td>Medium</td>
310 + </tr>
311 + </tbody>
312 + </table>
313 +
223 223   <p>
224 224   The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
225 225   understand the access model, critical features are documented and future upgrades can be planned with
... ... @@ -226,6 +226,24 @@
226 226   fewer surprises.
227 227   </p>
228 228  
320 + <h2 id="readiness-checklist">XWiki security review readiness checklist</h2>
321 +
322 + <p>
323 + Before starting a security review, prepare the following information. This makes the review faster and helps
324 + identify risks more clearly.
325 + </p>
326 +
327 + <ul class="resource-checklist">
328 + <li>Current XWiki version and target upgrade version, if an upgrade is planned.</li>
329 + <li>List of installed extensions and known custom applications.</li>
330 + <li>Authentication method: local users, LDAP, OIDC, SAML, SSO or MFA.</li>
331 + <li>Known restricted spaces, confidential areas or public-facing pages.</li>
332 + <li>List of technical administrators and users with powerful rights.</li>
333 + <li>Known custom scripts, templates, macros, UI extensions or Java components.</li>
334 + <li>Backup location, frequency and last restore test, if known.</li>
335 + <li>Staging or test environment availability.</li>
336 + </ul>
337 +
229 229   <h2 id="when-to-review">When should an XWiki security review be done?</h2>
230 230  
231 231   <p>
... ... @@ -239,72 +239,88 @@
239 239   permissions, extensions, customizations and recovery procedures were configured years earlier.
240 240   </p>
241 241  
242 - <div class="resource-note">
351 + <div class="resource-note related-resources">
352 + <p><strong>Security review series:</strong></p>
353 + <ul>
354 + <li>
355 + <a href="$xwiki.getURL('resources.xwiki-security-review')">What an XWiki security review should actually include</a>
356 + </li>
357 + <li>
358 + <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
359 + </li>
360 + <li>
361 + <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
362 + </li>
363 + </ul>
243 243   <p>
244 - <strong>Security review series:</strong>
245 - this article is the main overview. You can also read
246 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
247 - Future topics will cover authentication and access control, script and programming rights, backup validation,
248 - extension review and operational practices.
365 + Future topics will cover authentication and access control, script and programming rights,
366 + backup validation, extension review and operational practices.
249 249   </p>
250 250   </div>
251 251  
252 252   <h2 id="security-review-faq">XWiki security review FAQ</h2>
253 253  
254 - <h3>What should an XWiki security review include?</h3>
255 - <p>
256 - An XWiki security review should include the installed XWiki version, upgrade path,
257 - access rights, groups, authentication setup, installed extensions, custom code,
258 - infrastructure, backups, restore expectations and operational procedures.
259 - </p>
372 + <details class="resource-faq-item" open>
373 + <summary>What should an XWiki security review include?</summary>
374 + <p>
375 + An XWiki security review should include the installed XWiki version, upgrade path,
376 + access rights, groups, authentication setup, installed extensions, custom code,
377 + infrastructure, backups, restore expectations and operational procedures.
378 + </p>
379 + </details>
260 260  
261 - <h3>Is an updated XWiki instance automatically secure?</h3>
262 - <p>
263 - No. Updating XWiki is important, but security also depends on permissions,
264 - authentication, extensions, custom code, infrastructure configuration, backups
265 - and how the instance is maintained.
266 - </p>
381 + <details class="resource-faq-item">
382 + <summary>Is an updated XWiki instance automatically secure?</summary>
383 + <p>
384 + No. Updating XWiki is important, but security also depends on permissions,
385 + authentication, extensions, custom code, infrastructure configuration, backups
386 + and how the instance is maintained.
387 + </p>
388 + </details>
267 267  
268 - <h3>Does SSO solve XWiki access control?</h3>
269 - <p>
270 - No. SSO helps authenticate users, but access control still depends on XWiki groups,
271 - inherited permissions, page-level rights and administrative privileges.
272 - </p>
390 + <details class="resource-faq-item">
391 + <summary>Does SSO solve XWiki access control?</summary>
392 + <p>
393 + No. SSO helps authenticate users, but access control still depends on XWiki groups,
394 + inherited permissions, page-level rights and administrative privileges.
395 + </p>
396 + </details>
273 273  
274 - <h3>Why should custom code be reviewed?</h3>
275 - <p>
276 - Custom scripts, templates, macros, UI extensions and Java components can affect
277 - permissions, workflows, rendering, integrations and upgrade behavior. They should
278 - be identified, documented and tested.
279 - </p>
280 -
281 - <h3>When should an XWiki security review be done?</h3>
282 - <p>
283 - A review is useful before a major upgrade, after years of organic growth, after
284 - authentication changes, before exposing the wiki more broadly, or when the instance
285 - becomes business-critical.
286 - </p>
287 -
288 - <div class="resource-note">
398 + <details class="resource-faq-item">
399 + <summary>Why should custom code be reviewed?</summary>
289 289   <p>
290 - Related resources:
291 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>,
292 - <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
293 - and
294 - <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
401 + Custom scripts, templates, macros, UI extensions and Java components can affect
402 + permissions, workflows, rendering, integrations and upgrade behavior. They should
403 + be identified, documented and tested.
295 295   </p>
296 - </div>
405 + </details>
297 297  
298 - <div class="resource-cta">
299 - <h3>Need an XWiki security review?</h3>
407 + <details class="resource-faq-item">
408 + <summary>When should an XWiki security review be done?</summary>
300 300   <p>
301 - If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
302 - SSO, extensions and business-critical workflows, a structured review can help identify risks and define
303 - the safest next steps.
410 + A review is useful before a major upgrade, after years of organic growth, after
411 + authentication changes, before exposing the wiki more broadly, or when the instance
412 + becomes business-critical.
304 304   </p>
305 - <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
306 - </div>
414 + </details>
307 307  
416 + <div class="resource-note related-resources">
417 + <p><strong>Related resources:</strong></p>
418 + <ul>
419 + <li>
420 + <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
421 + </li>
422 + <li>
423 + <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
424 + </li>
425 + <li>
426 + <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">Why regular XWiki upgrades matter</a>
427 + </li>
428 + <li>
429 + <a href="$xwiki.getURL('resources.xwiki-custom-development')">How to keep XWiki custom development maintainable across upgrades</a>
430 + </li>
431 + </ul>
432 + </div>
308 308   </article>
309 309  
310 310   </div>
... ... @@ -311,6 +311,20 @@
311 311   </div>
312 312   </section>
313 313  
439 + <section class="cta-section" aria-labelledby="xwiki-security-review-cta-title">
440 + <div class="container">
441 + <div class="cta-panel">
442 + <h2 id="xwiki-security-review-cta-title">Need an XWiki security review?</h2>
443 + <p>
444 + If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
445 + SSO, extensions and business-critical workflows, a structured review can help identify risks and define
446 + the safest next steps.
447 + </p>
448 + <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
449 + </div>
450 + </div>
451 + </section>
452 +
314 314   <script type="application/ld+json">
315 315   {
316 316   "@context": "https://schema.org",