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

Summary

Details

Page properties
Content
... ... @@ -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.
... ... @@ -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
... ... @@ -177,11 +177,11 @@
177 177  
178 178   <div class="resource-inline-cta">
179 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.
168 + <strong>Not sure how risky your current XWiki version is?</strong>
169 + A short technical review can clarify the upgrade path, extension compatibility,
170 + custom code risks and validation needs before production is touched.
183 183   </p>
184 - <a class="btn btn-default" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
172 + <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a quick review</a>
185 185   </div>
186 186  
187 187   <h2 id="security-checklist">XWiki security review checklist</h2>
... ... @@ -244,87 +244,49 @@
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>
260 - <p>
261 - Future topics will cover authentication and access control, script and programming rights,
262 - backup validation, extension review and operational practices.
263 - </p>
264 - </div>
265 -
266 266   <h2 id="security-review-faq">XWiki security review FAQ</h2>
267 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>
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>
276 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>
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>
285 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>
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>
293 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>
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>
302 302  
303 - <details class="resource-faq-item">
304 - <summary>When should an XWiki security review be done?</summary>
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">
305 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.
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>.
309 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 328   </div>
329 329  
330 330   <div class="resource-cta">
xwiki-security-review.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.Admin
Size
... ... @@ -1,1 +1,0 @@
1 -1.3 MB
Content