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

Summary

Details

Page properties
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  
... ... @@ -45,11 +45,6 @@
45 45   </p>
46 46  
47 47   <p>
48 - An XWiki security review is a practical audit of the platform configuration, access model,
49 - authentication setup, installed extensions, custom code, infrastructure and recovery procedures.
50 - </p>
51 -
52 - <p>
53 53   Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
54 54   forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
55 55   weak fallback access or backup assumptions that were never tested.
... ... @@ -57,21 +57,6 @@
57 57  
58 58   <div class="resource-note">
59 59   <p>
60 - <strong>In practice:</strong> an XWiki security review should evaluate the XWiki version,
61 - access rights, authentication setup, installed extensions, custom code, infrastructure,
62 - backups, restore expectations and the operational practices used to maintain the instance.
63 - </p>
64 - </div>
65 -
66 - <p>
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.
71 - </p>
72 -
73 - <div class="resource-note">
74 - <p>
75 75   <strong>The main point:</strong> an XWiki security review should not only check whether the application
76 76   is online. It should evaluate the platform, the access model and the operational practices around it.
77 77   </p>
... ... @@ -109,11 +109,6 @@
109 109   A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
110 110   </p>
111 111  
112 - <p>
113 - For more details on upgrade planning, see
114 - <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>.
115 - </p>
116 -
117 117   <h3>2. Access rights and permission model</h3>
118 118   <p>
119 119   XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
... ... @@ -127,13 +127,6 @@
127 127   of small exceptions that nobody reviewed later.
128 128   </p>
129 129  
130 - <p>
131 - For a deeper look at this topic, see
132 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
133 - For a practical starting point, see
134 - <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">how to start an XWiki access-rights review</a>.
135 - </p>
136 -
137 137   <h3>3. Authentication and identity management</h3>
138 138   <p>
139 139   Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
... ... @@ -158,11 +158,6 @@
158 158   discovered accidentally during an incident or a production upgrade.
159 159   </p>
160 160  
161 - <p>
162 - Customizations should also be reviewed from a maintenance perspective. See
163 - <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
164 - </p>
165 -
166 166   <h3>5. Configuration, infrastructure and operations</h3>
167 167   <p>
168 168   The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
... ... @@ -175,22 +175,8 @@
175 175   knows what is included, how long recovery would take or whether the restore process has ever been tested.
176 176   </p>
177 177  
178 - <div class="resource-inline-cta">
179 - <p>
180 - <strong>Need a clearer view of your XWiki security posture?</strong>
181 - A structured review can check versions, access rights, authentication,
182 - extensions, custom code, infrastructure, backups and operational practices.
183 - </p>
184 - <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
185 - </div>
140 + <h2 id="security-checklist">Practical XWiki security review checklist</h2>
186 186  
187 - <h2 id="security-checklist">XWiki security review checklist</h2>
188 -
189 - <p>
190 - A practical XWiki security review should cover both application-level and operational risks.
191 - The following checklist can be used as a starting point when reviewing a production instance.
192 - </p>
193 -
194 194   <ul class="resource-checklist">
195 195   <li>Check the current XWiki version, target version and upgrade path.</li>
196 196   <li>Review installed extensions, outdated components and unsupported customizations.</li>
... ... @@ -207,7 +207,7 @@
207 207   <h2 id="review-output">What the review should produce</h2>
208 208  
209 209   <p>
210 - 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
211 211   plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
212 212   </p>
213 213  
... ... @@ -217,14 +217,6 @@
217 217   reviewing extensions or preparing the next upgrade.
218 218   </p>
219 219  
220 - <div class="resource-note">
221 - <p>
222 - <strong>A useful review should separate findings by priority:</strong> immediate risks,
223 - planned remediation, maintenance improvements and documentation gaps. This makes the result
224 - easier to act on instead of producing a generic list of observations.
225 - </p>
226 - </div>
227 -
228 228   <p>
229 229   The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
230 230   understand the access model, critical features are documented and future upgrades can be planned with
... ... @@ -244,89 +244,15 @@
244 244   permissions, extensions, customizations and recovery procedures were configured years earlier.
245 245   </p>
246 246  
247 - <div class="resource-note related-resources">
248 - <p><strong>Security review series:</strong></p>
249 - <ul>
250 - <li>
251 - <a href="$xwiki.getURL('resources.xwiki-security-review')">What an XWiki security review should actually include</a>
252 - </li>
253 - <li>
254 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
255 - </li>
256 - <li>
257 - <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
258 - </li>
259 - </ul>
187 + <div class="resource-note">
260 260   <p>
261 - Future topics will cover authentication and access control, script and programming rights,
262 - 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>.
263 263   </p>
264 264   </div>
265 265  
266 - <h2 id="security-review-faq">XWiki security review FAQ</h2>
267 -
268 - <details class="resource-faq-item" open>
269 - <summary>What should an XWiki security review include?</summary>
270 - <p>
271 - An XWiki security review should include the installed XWiki version, upgrade path,
272 - access rights, groups, authentication setup, installed extensions, custom code,
273 - infrastructure, backups, restore expectations and operational procedures.
274 - </p>
275 - </details>
276 -
277 - <details class="resource-faq-item">
278 - <summary>Is an updated XWiki instance automatically secure?</summary>
279 - <p>
280 - No. Updating XWiki is important, but security also depends on permissions,
281 - authentication, extensions, custom code, infrastructure configuration, backups
282 - and how the instance is maintained.
283 - </p>
284 - </details>
285 -
286 - <details class="resource-faq-item">
287 - <summary>Does SSO solve XWiki access control?</summary>
288 - <p>
289 - No. SSO helps authenticate users, but access control still depends on XWiki groups,
290 - inherited permissions, page-level rights and administrative privileges.
291 - </p>
292 - </details>
293 -
294 - <details class="resource-faq-item">
295 - <summary>Why should custom code be reviewed?</summary>
296 - <p>
297 - Custom scripts, templates, macros, UI extensions and Java components can affect
298 - permissions, workflows, rendering, integrations and upgrade behavior. They should
299 - be identified, documented and tested.
300 - </p>
301 - </details>
302 -
303 - <details class="resource-faq-item">
304 - <summary>When should an XWiki security review be done?</summary>
305 - <p>
306 - A review is useful before a major upgrade, after years of organic growth, after
307 - authentication changes, before exposing the wiki more broadly, or when the instance
308 - becomes business-critical.
309 - </p>
310 - </details>
311 -
312 - <div class="resource-note related-resources">
313 - <p><strong>Related resources:</strong></p>
314 - <ul>
315 - <li>
316 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
317 - </li>
318 - <li>
319 - <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">How to start an XWiki access-rights review</a>
320 - </li>
321 - <li>
322 - <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">Why regular XWiki upgrades matter</a>
323 - </li>
324 - <li>
325 - <a href="$xwiki.getURL('resources.xwiki-custom-development')">How to keep XWiki custom development maintainable across upgrades</a>
326 - </li>
327 - </ul>
328 - </div>
329 -
330 330   <div class="resource-cta">
331 331   <h3>Need an XWiki security review?</h3>
332 332   <p>
... ... @@ -343,54 +343,5 @@
343 343   </div>
344 344   </section>
345 345  
346 - <script type="application/ld+json">
347 - {
348 - "@context": "https://schema.org",
349 - "@type": "FAQPage",
350 - "mainEntity": [
351 - {
352 - "@type": "Question",
353 - "name": "What should an XWiki security review include?",
354 - "acceptedAnswer": {
355 - "@type": "Answer",
356 - "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."
357 - }
358 - },
359 - {
360 - "@type": "Question",
361 - "name": "Is an updated XWiki instance automatically secure?",
362 - "acceptedAnswer": {
363 - "@type": "Answer",
364 - "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."
365 - }
366 - },
367 - {
368 - "@type": "Question",
369 - "name": "Does SSO solve XWiki access control?",
370 - "acceptedAnswer": {
371 - "@type": "Answer",
372 - "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges."
373 - }
374 - },
375 - {
376 - "@type": "Question",
377 - "name": "Why should custom code be reviewed in XWiki?",
378 - "acceptedAnswer": {
379 - "@type": "Answer",
380 - "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."
381 - }
382 - },
383 - {
384 - "@type": "Question",
385 - "name": "When should an XWiki security review be done?",
386 - "acceptedAnswer": {
387 - "@type": "Answer",
388 - "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."
389 - }
390 - }
391 - ]
392 - }
393 - </script>
394 -
395 395  {{/html}}
396 396  {{/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