Skip to Content
Last modified by Alex Cotiuga on 2026/07/13 06:44
From version 4.5
edited by Alex Cotiuga
on 2026/07/13 06:44
Change comment: There is no comment for this version
To version 3.1
edited by Alex Cotiuga
on 2026/05/26 15:27
Change comment: Upload new image "xwiki-security-review.png", version 1.1

Summary

Details

Page properties
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Hidden
... ... @@ -1,1 +1,1 @@
1 -true
1 +false
Content
... ... @@ -28,12 +28,9 @@
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>
32 32   <li><a href="#what-to-review">What to review</a></li>
33 - <li><a href="#common-findings">Common findings</a></li>
34 34   <li><a href="#security-checklist">Security checklist</a></li>
35 35   <li><a href="#review-output">What the review should produce</a></li>
36 - <li><a href="#readiness-checklist">What to prepare</a></li>
37 37   <li><a href="#when-to-review">When to run a review</a></li>
38 38   <li><a href="#security-review-faq">FAQ</a></li>
39 39   </ul>
... ... @@ -48,11 +48,6 @@
48 48   </p>
49 49  
50 50   <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>
56 56   Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
57 57   forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
58 58   weak fallback access or backup assumptions that were never tested.
... ... @@ -67,9 +67,10 @@
67 67   </div>
68 68  
69 69   <p>
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.
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.
73 73   </p>
74 74  
75 75   <div class="resource-note">
... ... @@ -93,34 +93,10 @@
93 93   </p>
94 94  
95 95   <p>
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.
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.
99 99   </p>
100 100  
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 -
124 124   <h2 id="what-to-review">What should be reviewed</h2>
125 125  
126 126   <h3>1. Version and upgrade status</h3>
... ... @@ -153,13 +153,6 @@
153 153   of small exceptions that nobody reviewed later.
154 154   </p>
155 155  
156 - <p>
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>.
161 - </p>
162 -
163 163   <h3>3. Authentication and identity management</h3>
164 164   <p>
165 165   Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
... ... @@ -207,42 +207,9 @@
207 207   A structured review can check versions, access rights, authentication,
208 208   extensions, custom code, infrastructure, backups and operational practices.
209 209   </p>
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>
172 + <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
212 212   </div>
213 213  
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 -
246 246   <h2 id="security-checklist">XWiki security review checklist</h2>
247 247  
248 248   <p>
... ... @@ -266,8 +266,8 @@
266 266   <h2 id="review-output">What the review should produce</h2>
267 267  
268 268   <p>
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.
198 + A useful security review should not only produce a list of detected problems. It should produce a practical action
199 + plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
271 271   </p>
272 272  
273 273   <p>
... ... @@ -284,33 +284,6 @@
284 284   </p>
285 285   </div>
286 286  
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 -
314 314   <p>
315 315   The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
316 316   understand the access model, critical features are documented and future upgrades can be planned with
... ... @@ -317,24 +317,6 @@
317 317   fewer surprises.
318 318   </p>
319 319  
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 -
338 338   <h2 id="when-to-review">When should an XWiki security review be done?</h2>
339 339  
340 340   <p>
... ... @@ -348,88 +348,61 @@
348 348   permissions, extensions, customizations and recovery procedures were configured years earlier.
349 349   </p>
350 350  
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>
364 - <p>
365 - Future topics will cover authentication and access control, script and programming rights,
366 - backup validation, extension review and operational practices.
367 - </p>
368 - </div>
369 -
370 370   <h2 id="security-review-faq">XWiki security review FAQ</h2>
371 371  
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>
237 + <h3>What should an XWiki security review include?</h3>
238 + <p>
239 + An XWiki security review should include the installed XWiki version, upgrade path,
240 + access rights, groups, authentication setup, installed extensions, custom code,
241 + infrastructure, backups, restore expectations and operational procedures.
242 + </p>
380 380  
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>
244 + <h3>Is an updated XWiki instance automatically secure?</h3>
245 + <p>
246 + No. Updating XWiki is important, but security also depends on permissions,
247 + authentication, extensions, custom code, infrastructure configuration, backups
248 + and how the instance is maintained.
249 + </p>
389 389  
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>
251 + <h3>Does SSO solve XWiki access control?</h3>
252 + <p>
253 + No. SSO helps authenticate users, but access control still depends on XWiki groups,
254 + inherited permissions, page-level rights and administrative privileges.
255 + </p>
397 397  
398 - <details class="resource-faq-item">
399 - <summary>Why should custom code be reviewed?</summary>
257 + <h3>Why should custom code be reviewed?</h3>
258 + <p>
259 + Custom scripts, templates, macros, UI extensions and Java components can affect
260 + permissions, workflows, rendering, integrations and upgrade behavior. They should
261 + be identified, documented and tested.
262 + </p>
263 +
264 + <h3>When should an XWiki security review be done?</h3>
265 + <p>
266 + A review is useful before a major upgrade, after years of organic growth, after
267 + authentication changes, before exposing the wiki more broadly, or when the instance
268 + becomes business-critical.
269 + </p>
270 +
271 + <div class="resource-note">
400 400   <p>
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.
273 + Related resources:
274 + <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
275 + and
276 + <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
404 404   </p>
405 - </details>
278 + </div>
406 406  
407 - <details class="resource-faq-item">
408 - <summary>When should an XWiki security review be done?</summary>
280 + <div class="resource-cta">
281 + <h3>Need an XWiki security review?</h3>
409 409   <p>
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.
283 + If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
284 + SSO, extensions and business-critical workflows, a structured review can help identify risks and define
285 + the safest next steps.
413 413   </p>
414 - </details>
415 -
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>
287 + <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
432 432   </div>
289 +
433 433   </article>
434 434  
435 435   </div>
... ... @@ -436,20 +436,6 @@
436 436   </div>
437 437   </section>
438 438  
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 -
453 453   <script type="application/ld+json">
454 454   {
455 455   "@context": "https://schema.org",