Skip to Content
Last modified by Agnease on 2026/06/08 18:44
From version 3.4
edited by Agnease
on 2026/06/02 11:06
Change comment: There is no comment for this version
To version 1.7
edited by Agnease
on 2026/05/26 09:14
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  
... ... @@ -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,10 +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 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
127 - </p>
128 -
129 129   <h3>3. Authentication and identity management</h3>
130 130   <p>
131 131   Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
... ... @@ -150,11 +150,6 @@
150 150   discovered accidentally during an incident or a production upgrade.
151 151   </p>
152 152  
153 - <p>
154 - Customizations should also be reviewed from a maintenance perspective. See
155 - <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
156 - </p>
157 -
158 158   <h3>5. Configuration, infrastructure and operations</h3>
159 159   <p>
160 160   The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
... ... @@ -167,22 +167,8 @@
167 167   knows what is included, how long recovery would take or whether the restore process has ever been tested.
168 168   </p>
169 169  
170 - <div class="resource-inline-cta">
171 - <p>
172 - <strong>Need a clearer view of your XWiki security posture?</strong>
173 - A structured review can check versions, access rights, authentication,
174 - extensions, custom code, infrastructure, backups and operational practices.
175 - </p>
176 - <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
177 - </div>
140 + <h2 id="security-checklist">Practical XWiki security review checklist</h2>
178 178  
179 - <h2 id="security-checklist">XWiki security review checklist</h2>
180 -
181 - <p>
182 - A practical XWiki security review should cover both application-level and operational risks.
183 - The following checklist can be used as a starting point when reviewing a production instance.
184 - </p>
185 -
186 186   <ul class="resource-checklist">
187 187   <li>Check the current XWiki version, target version and upgrade path.</li>
188 188   <li>Review installed extensions, outdated components and unsupported customizations.</li>
... ... @@ -209,14 +209,6 @@
209 209   reviewing extensions or preparing the next upgrade.
210 210   </p>
211 211  
212 - <div class="resource-note">
213 - <p>
214 - <strong>A useful review should separate findings by priority:</strong> immediate risks,
215 - planned remediation, maintenance improvements and documentation gaps. This makes the result
216 - easier to act on instead of producing a generic list of observations.
217 - </p>
218 - </div>
219 -
220 220   <p>
221 221   The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
222 222   understand the access model, critical features are documented and future upgrades can be planned with
... ... @@ -238,54 +238,7 @@
238 238  
239 239   <div class="resource-note">
240 240   <p>
241 - <strong>Security review series:</strong>
242 - this article is the main overview. You can also read
243 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>.
244 - Future topics will cover authentication and access control, script and programming rights, backup validation,
245 - extension review and operational practices.
246 - </p>
247 - </div>
248 -
249 - <h2 id="security-review-faq">XWiki security review FAQ</h2>
250 -
251 - <h3>What should an XWiki security review include?</h3>
252 - <p>
253 - An XWiki security review should include the installed XWiki version, upgrade path,
254 - access rights, groups, authentication setup, installed extensions, custom code,
255 - infrastructure, backups, restore expectations and operational procedures.
256 - </p>
257 -
258 - <h3>Is an updated XWiki instance automatically secure?</h3>
259 - <p>
260 - No. Updating XWiki is important, but security also depends on permissions,
261 - authentication, extensions, custom code, infrastructure configuration, backups
262 - and how the instance is maintained.
263 - </p>
264 -
265 - <h3>Does SSO solve XWiki access control?</h3>
266 - <p>
267 - No. SSO helps authenticate users, but access control still depends on XWiki groups,
268 - inherited permissions, page-level rights and administrative privileges.
269 - </p>
270 -
271 - <h3>Why should custom code be reviewed?</h3>
272 - <p>
273 - Custom scripts, templates, macros, UI extensions and Java components can affect
274 - permissions, workflows, rendering, integrations and upgrade behavior. They should
275 - be identified, documented and tested.
276 - </p>
277 -
278 - <h3>When should an XWiki security review be done?</h3>
279 - <p>
280 - A review is useful before a major upgrade, after years of organic growth, after
281 - authentication changes, before exposing the wiki more broadly, or when the instance
282 - becomes business-critical.
283 - </p>
284 -
285 - <div class="resource-note">
286 - <p>
287 287   Related resources:
288 - <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>,
289 289   <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
290 290   and
291 291   <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
... ... @@ -308,54 +308,5 @@
308 308   </div>
309 309   </section>
310 310  
311 - <script type="application/ld+json">
312 - {
313 - "@context": "https://schema.org",
314 - "@type": "FAQPage",
315 - "mainEntity": [
316 - {
317 - "@type": "Question",
318 - "name": "What should an XWiki security review include?",
319 - "acceptedAnswer": {
320 - "@type": "Answer",
321 - "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."
322 - }
323 - },
324 - {
325 - "@type": "Question",
326 - "name": "Is an updated XWiki instance automatically secure?",
327 - "acceptedAnswer": {
328 - "@type": "Answer",
329 - "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."
330 - }
331 - },
332 - {
333 - "@type": "Question",
334 - "name": "Does SSO solve XWiki access control?",
335 - "acceptedAnswer": {
336 - "@type": "Answer",
337 - "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges."
338 - }
339 - },
340 - {
341 - "@type": "Question",
342 - "name": "Why should custom code be reviewed in XWiki?",
343 - "acceptedAnswer": {
344 - "@type": "Answer",
345 - "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."
346 - }
347 - },
348 - {
349 - "@type": "Question",
350 - "name": "When should an XWiki security review be done?",
351 - "acceptedAnswer": {
352 - "@type": "Answer",
353 - "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."
354 - }
355 - }
356 - ]
357 - }
358 - </script>
359 -
360 360  {{/html}}
361 361  {{/velocity}}
xwiki-security-review.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.Admin
Size
... ... @@ -1,1 +1,0 @@
1 -1.3 MB
Content