Skip to Content
Last modified by Agnease on 2026/06/08 18:44
From version 1.3
edited by Agnease
on 2026/05/26 07:46
Change comment: There is no comment for this version
To version 3.8
edited by Agnease
on 2026/06/08 18:25
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -32,6 +32,7 @@
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>
34 34   <li><a href="#when-to-review">When to run a review</a></li>
35 + <li><a href="#security-review-faq">FAQ</a></li>
35 35   </ul>
36 36   </aside>
37 37  
... ... @@ -51,6 +51,21 @@
51 51  
52 52   <div class="resource-note">
53 53   <p>
55 + <strong>In practice:</strong> an XWiki security review should evaluate the XWiki version,
56 + access rights, authentication setup, installed extensions, custom code, infrastructure,
57 + backups, restore expectations and the operational practices used to maintain the instance.
58 + </p>
59 + </div>
60 +
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.
66 + </p>
67 +
68 + <div class="resource-note">
69 + <p>
54 54   <strong>The main point:</strong> an XWiki security review should not only check whether the application
55 55   is online. It should evaluate the platform, the access model and the operational practices around it.
56 56   </p>
... ... @@ -88,6 +88,11 @@
88 88   A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
89 89   </p>
90 90  
107 + <p>
108 + For more details on upgrade planning, see
109 + <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>.
110 + </p>
111 +
91 91   <h3>2. Access rights and permission model</h3>
92 92   <p>
93 93   XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
... ... @@ -101,6 +101,13 @@
101 101   of small exceptions that nobody reviewed later.
102 102   </p>
103 103  
125 + <p>
126 + For a deeper look at this topic, see
127 + <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
128 + For a practical starting point, see
129 + <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">how to start an XWiki access-rights review</a>.
130 + </p>
131 +
104 104   <h3>3. Authentication and identity management</h3>
105 105   <p>
106 106   Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
... ... @@ -125,6 +125,11 @@
125 125   discovered accidentally during an incident or a production upgrade.
126 126   </p>
127 127  
156 + <p>
157 + Customizations should also be reviewed from a maintenance perspective. See
158 + <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
159 + </p>
160 +
128 128   <h3>5. Configuration, infrastructure and operations</h3>
129 129   <p>
130 130   The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
... ... @@ -137,8 +137,22 @@
137 137   knows what is included, how long recovery would take or whether the restore process has ever been tested.
138 138   </p>
139 139  
140 - <h2 id="security-checklist">Practical XWiki security review checklist</h2>
173 + <div class="resource-inline-cta">
174 + <p>
175 + <strong>Need a clearer view of your XWiki security posture?</strong>
176 + A structured review can check versions, access rights, authentication,
177 + extensions, custom code, infrastructure, backups and operational practices.
178 + </p>
179 + <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
180 + </div>
141 141  
182 + <h2 id="security-checklist">XWiki security review checklist</h2>
183 +
184 + <p>
185 + A practical XWiki security review should cover both application-level and operational risks.
186 + The following checklist can be used as a starting point when reviewing a production instance.
187 + </p>
188 +
142 142   <ul class="resource-checklist">
143 143   <li>Check the current XWiki version, target version and upgrade path.</li>
144 144   <li>Review installed extensions, outdated components and unsupported customizations.</li>
... ... @@ -155,7 +155,7 @@
155 155   <h2 id="review-output">What the review should produce</h2>
156 156  
157 157   <p>
158 - A useful security review should not only produce a list of problems. It should produce a practical action
205 + A useful security review should not only produce a list of detected problems. It should produce a practical action
159 159   plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
160 160   </p>
161 161  
... ... @@ -165,6 +165,14 @@
165 165   reviewing extensions or preparing the next upgrade.
166 166   </p>
167 167  
215 + <div class="resource-note">
216 + <p>
217 + <strong>A useful review should separate findings by priority:</strong> immediate risks,
218 + planned remediation, maintenance improvements and documentation gaps. This makes the result
219 + easier to act on instead of producing a generic list of observations.
220 + </p>
221 + </div>
222 +
168 168   <p>
169 169   The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
170 170   understand the access model, critical features are documented and future upgrades can be planned with
... ... @@ -184,15 +184,79 @@
184 184   permissions, extensions, customizations and recovery procedures were configured years earlier.
185 185   </p>
186 186  
187 - <div class="resource-note">
242 + <div class="resource-note related-resources">
243 + <p><strong>Security review series:</strong></p>
244 + <ul>
245 + <li>
246 + <a href="$xwiki.getURL('resources.xwiki-security-review')">What an XWiki security review should actually include</a>
247 + </li>
248 + <li>
249 + <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
250 + </li>
251 + <li>
252 + <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
253 + </li>
254 + </ul>
188 188   <p>
189 - Related resources:
190 - <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
191 - and
192 - <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
256 + Future topics will cover authentication and access control, script and programming rights,
257 + backup validation, extension review and operational practices.
193 193   </p>
194 194   </div>
195 195  
261 + <h2 id="security-review-faq">XWiki security review FAQ</h2>
262 +
263 + <h3>What should an XWiki security review include?</h3>
264 + <p>
265 + An XWiki security review should include the installed XWiki version, upgrade path,
266 + access rights, groups, authentication setup, installed extensions, custom code,
267 + infrastructure, backups, restore expectations and operational procedures.
268 + </p>
269 +
270 + <h3>Is an updated XWiki instance automatically secure?</h3>
271 + <p>
272 + No. Updating XWiki is important, but security also depends on permissions,
273 + authentication, extensions, custom code, infrastructure configuration, backups
274 + and how the instance is maintained.
275 + </p>
276 +
277 + <h3>Does SSO solve XWiki access control?</h3>
278 + <p>
279 + No. SSO helps authenticate users, but access control still depends on XWiki groups,
280 + inherited permissions, page-level rights and administrative privileges.
281 + </p>
282 +
283 + <h3>Why should custom code be reviewed?</h3>
284 + <p>
285 + Custom scripts, templates, macros, UI extensions and Java components can affect
286 + permissions, workflows, rendering, integrations and upgrade behavior. They should
287 + be identified, documented and tested.
288 + </p>
289 +
290 + <h3>When should an XWiki security review be done?</h3>
291 + <p>
292 + A review is useful before a major upgrade, after years of organic growth, after
293 + authentication changes, before exposing the wiki more broadly, or when the instance
294 + becomes business-critical.
295 + </p>
296 +
297 + <div class="resource-note related-resources">
298 + <p><strong>Related resources:</strong></p>
299 + <ul>
300 + <li>
301 + <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
302 + </li>
303 + <li>
304 + <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
305 + </li>
306 + <li>
307 + <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">Why regular XWiki upgrades matter</a>
308 + </li>
309 + <li>
310 + <a href="$xwiki.getURL('resources.xwiki-custom-development')">How to keep XWiki custom development maintainable across upgrades</a>
311 + </li>
312 + </ul>
313 + </div>
314 +
196 196   <div class="resource-cta">
197 197   <h3>Need an XWiki security review?</h3>
198 198   <p>
... ... @@ -209,5 +209,54 @@
209 209   </div>
210 210   </section>
211 211  
331 + <script type="application/ld+json">
332 + {
333 + "@context": "https://schema.org",
334 + "@type": "FAQPage",
335 + "mainEntity": [
336 + {
337 + "@type": "Question",
338 + "name": "What should an XWiki security review include?",
339 + "acceptedAnswer": {
340 + "@type": "Answer",
341 + "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."
342 + }
343 + },
344 + {
345 + "@type": "Question",
346 + "name": "Is an updated XWiki instance automatically secure?",
347 + "acceptedAnswer": {
348 + "@type": "Answer",
349 + "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."
350 + }
351 + },
352 + {
353 + "@type": "Question",
354 + "name": "Does SSO solve XWiki access control?",
355 + "acceptedAnswer": {
356 + "@type": "Answer",
357 + "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges."
358 + }
359 + },
360 + {
361 + "@type": "Question",
362 + "name": "Why should custom code be reviewed in XWiki?",
363 + "acceptedAnswer": {
364 + "@type": "Answer",
365 + "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."
366 + }
367 + },
368 + {
369 + "@type": "Question",
370 + "name": "When should an XWiki security review be done?",
371 + "acceptedAnswer": {
372 + "@type": "Answer",
373 + "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."
374 + }
375 + }
376 + ]
377 + }
378 + </script>
379 +
212 212  {{/html}}
213 213  {{/velocity}}
xwiki-security-review.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.Admin
Size
... ... @@ -1,0 +1,1 @@
1 +1.3 MB
Content
Agnease.Code.SEODetailsClass[0]
metaDescription
... ... @@ -1,0 +1,1 @@
1 +Learn what an XWiki security review should include: version status, access rights, authentication, extensions, custom code, infrastructure, backups and operational practices.
metaTitle
... ... @@ -1,0 +1,1 @@
1 +What an XWiki Security Review Should Actually Include | Agnease