Changes for page What an XWiki Security Review Should Actually Include
Last modified by Agnease on 2026/06/08 18:44
Summary
-
Page properties (1 modified, 0 added, 0 removed)
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. ... ... @@ -128,10 +128,7 @@ 128 128 </p> 129 129 130 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>. 126 + For a deeper look at this topic, see <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>. 135 135 </p> 136 136 137 137 <h3>3. Authentication and identity management</h3> ... ... @@ -181,7 +181,7 @@ 181 181 A structured review can check versions, access rights, authentication, 182 182 extensions, custom code, infrastructure, backups and operational practices. 183 183 </p> 184 - <a class="btn btn- primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>176 + <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a security 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> 241 + <h3>What should an XWiki security review include?</h3> 242 + <p> 243 + An XWiki security review should include the installed XWiki version, upgrade path, 244 + access rights, groups, authentication setup, installed extensions, custom code, 245 + infrastructure, backups, restore expectations and operational procedures. 246 + </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> 248 + <h3>Is an updated XWiki instance automatically secure?</h3> 249 + <p> 250 + No. Updating XWiki is important, but security also depends on permissions, 251 + authentication, extensions, custom code, infrastructure configuration, backups 252 + and how the instance is maintained. 253 + </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> 255 + <h3>Does SSO solve XWiki access control?</h3> 256 + <p> 257 + No. SSO helps authenticate users, but access control still depends on XWiki groups, 258 + inherited permissions, page-level rights and administrative privileges. 259 + </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> 261 + <h3>Why should custom code be reviewed?</h3> 262 + <p> 263 + Custom scripts, templates, macros, UI extensions and Java components can affect 264 + permissions, workflows, rendering, integrations and upgrade behavior. They should 265 + be identified, documented and tested. 266 + </p> 302 302 303 - <details class="resource-faq-item"> 304 - <summary>When should an XWiki security review be done?</summary> 268 + <h3>When should an XWiki security review be done?</h3> 269 + <p> 270 + A review is useful before a major upgrade, after years of organic growth, after 271 + authentication changes, before exposing the wiki more broadly, or when the instance 272 + becomes business-critical. 273 + </p> 274 + 275 + <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. 277 + Related resources: 278 + <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a> 279 + and 280 + <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">