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

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -What an XWiki Security Review Should Actually Include
1 +xwiki-security-review
Content
... ... @@ -32,7 +32,6 @@
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>
36 36   </ul>
37 37   </aside>
38 38  
... ... @@ -52,21 +52,6 @@
52 52  
53 53   <div class="resource-note">
54 54   <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>
70 70   <strong>The main point:</strong> an XWiki security review should not only check whether the application
71 71   is online. It should evaluate the platform, the access model and the operational practices around it.
72 72   </p>
... ... @@ -104,11 +104,6 @@
104 104   A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
105 105   </p>
106 106  
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 -
112 112   <h3>2. Access rights and permission model</h3>
113 113   <p>
114 114   XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
... ... @@ -122,13 +122,6 @@
122 122   of small exceptions that nobody reviewed later.
123 123   </p>
124 124  
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 -
132 132   <h3>3. Authentication and identity management</h3>
133 133   <p>
134 134   Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
... ... @@ -153,11 +153,6 @@
153 153   discovered accidentally during an incident or a production upgrade.
154 154   </p>
155 155  
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 -
161 161   <h3>5. Configuration, infrastructure and operations</h3>
162 162   <p>
163 163   The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
... ... @@ -170,22 +170,8 @@
170 170   knows what is included, how long recovery would take or whether the restore process has ever been tested.
171 171   </p>
172 172  
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>
140 + <h2 id="security-checklist">Practical XWiki security review checklist</h2>
181 181  
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 -
189 189   <ul class="resource-checklist">
190 190   <li>Check the current XWiki version, target version and upgrade path.</li>
191 191   <li>Review installed extensions, outdated components and unsupported customizations.</li>
... ... @@ -202,7 +202,7 @@
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
158 + A useful security review should not only produce a list of problems. It should produce a practical action
206 206   plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
207 207   </p>
208 208  
... ... @@ -212,14 +212,6 @@
212 212   reviewing extensions or preparing the next upgrade.
213 213   </p>
214 214  
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 -
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
... ... @@ -239,79 +239,15 @@
239 239   permissions, extensions, customizations and recovery procedures were configured years earlier.
240 240   </p>
241 241  
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>
187 + <div class="resource-note">
255 255   <p>
256 - Future topics will cover authentication and access control, script and programming rights,
257 - backup validation, extension review and operational practices.
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>.
258 258   </p>
259 259   </div>
260 260  
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 -
315 315   <div class="resource-cta">
316 316   <h3>Need an XWiki security review?</h3>
317 317   <p>
... ... @@ -328,54 +328,5 @@
328 328   </div>
329 329   </section>
330 330  
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 -
380 380  {{/html}}
381 381  {{/velocity}}
xwiki-security-review.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.Admin
Size
... ... @@ -1,1 +1,0 @@
1 -1.3 MB
Content
Agnease.Code.SEODetailsClass[0]
metaDescription
... ... @@ -1,1 +1,0 @@
1 -Learn what an XWiki security review should include: version status, access rights, authentication, extensions, custom code, infrastructure, backups and operational practices.
metaTitle
... ... @@ -1,1 +1,0 @@
1 -What an XWiki Security Review Should Actually Include | Agnease