Skip to Content
Last modified by Agnease on 2026/06/08 18:44
From version 3.12
edited by Agnease
on 2026/06/08 18:44
Change comment: There is no comment for this version
To version 3.11
edited by Agnease
on 2026/06/08 18:30
Change comment: There is no comment for this version

Summary

Details

Page properties
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>
... ... @@ -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.
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.
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.
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.
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>
... ... @@ -210,38 +210,6 @@
210 210   <a class="btn btn-default" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
211 211   </div>
212 212  
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 -
245 245   <h2 id="security-checklist">XWiki security review checklist</h2>
246 246  
247 247   <p>
... ... @@ -265,8 +265,8 @@
265 265   <h2 id="review-output">What the review should produce</h2>
266 266  
267 267   <p>
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.
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.
270 270   </p>
271 271  
272 272   <p>
... ... @@ -283,33 +283,6 @@
283 283   </p>
284 284   </div>
285 285  
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 -
313 313   <p>
314 314   The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
315 315   understand the access model, critical features are documented and future upgrades can be planned with
... ... @@ -316,24 +316,6 @@
316 316   fewer surprises.
317 317   </p>
318 318  
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 -
337 337   <h2 id="when-to-review">When should an XWiki security review be done?</h2>
338 338  
339 339   <p>