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)
-
Attachments (0 modified, 0 added, 1 removed)
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 ... ... @@ -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> ... ... @@ -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 ... ... @@ -241,57 +241,7 @@ 241 241 242 242 <div class="resource-note"> 243 243 <p> 244 - <strong>Security review series:</strong> 245 - this article is the main overview. You can also read 246 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a> 247 - and 248 - <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">how to start an XWiki access-rights review</a>. 249 - Future topics will cover authentication and access control, script and programming rights, backup validation, 250 - extension review and operational practices. 251 - </p> 252 - </div> 253 - 254 - <h2 id="security-review-faq">XWiki security review FAQ</h2> 255 - 256 - <h3>What should an XWiki security review include?</h3> 257 - <p> 258 - An XWiki security review should include the installed XWiki version, upgrade path, 259 - access rights, groups, authentication setup, installed extensions, custom code, 260 - infrastructure, backups, restore expectations and operational procedures. 261 - </p> 262 - 263 - <h3>Is an updated XWiki instance automatically secure?</h3> 264 - <p> 265 - No. Updating XWiki is important, but security also depends on permissions, 266 - authentication, extensions, custom code, infrastructure configuration, backups 267 - and how the instance is maintained. 268 - </p> 269 - 270 - <h3>Does SSO solve XWiki access control?</h3> 271 - <p> 272 - No. SSO helps authenticate users, but access control still depends on XWiki groups, 273 - inherited permissions, page-level rights and administrative privileges. 274 - </p> 275 - 276 - <h3>Why should custom code be reviewed?</h3> 277 - <p> 278 - Custom scripts, templates, macros, UI extensions and Java components can affect 279 - permissions, workflows, rendering, integrations and upgrade behavior. They should 280 - be identified, documented and tested. 281 - </p> 282 - 283 - <h3>When should an XWiki security review be done?</h3> 284 - <p> 285 - A review is useful before a major upgrade, after years of organic growth, after 286 - authentication changes, before exposing the wiki more broadly, or when the instance 287 - becomes business-critical. 288 - </p> 289 - 290 - <div class="resource-note"> 291 - <p> 292 292 Related resources: 293 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>, 294 - <a href="$xwiki.getURL('resources.xwiki-access-rights-review')">how to start an XWiki access-rights review</a>, 295 295 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a> 296 296 and 297 297 <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>. ... ... @@ -314,54 +314,5 @@ 314 314 </div> 315 315 </section> 316 316 317 - <script type="application/ld+json"> 318 - { 319 - "@context": "https://schema.org", 320 - "@type": "FAQPage", 321 - "mainEntity": [ 322 - { 323 - "@type": "Question", 324 - "name": "What should an XWiki security review include?", 325 - "acceptedAnswer": { 326 - "@type": "Answer", 327 - "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." 328 - } 329 - }, 330 - { 331 - "@type": "Question", 332 - "name": "Is an updated XWiki instance automatically secure?", 333 - "acceptedAnswer": { 334 - "@type": "Answer", 335 - "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." 336 - } 337 - }, 338 - { 339 - "@type": "Question", 340 - "name": "Does SSO solve XWiki access control?", 341 - "acceptedAnswer": { 342 - "@type": "Answer", 343 - "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges." 344 - } 345 - }, 346 - { 347 - "@type": "Question", 348 - "name": "Why should custom code be reviewed in XWiki?", 349 - "acceptedAnswer": { 350 - "@type": "Answer", 351 - "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." 352 - } 353 - }, 354 - { 355 - "@type": "Question", 356 - "name": "When should an XWiki security review be done?", 357 - "acceptedAnswer": { 358 - "@type": "Answer", 359 - "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." 360 - } 361 - } 362 - ] 363 - } 364 - </script> 365 - 366 366 {{/html}} 367 367 {{/velocity}}
- xwiki-security-review.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.Admin - Size
-
... ... @@ -1,1 +1,0 @@ 1 -1.3 MB - Content