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

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -xwiki-security-review
1 +What an XWiki Security Review Should Actually Include
Content
... ... @@ -1,0 +1,396 @@
1 +{{velocity}}
2 +#set ($discard = $xwiki.ssx.use('PublicWebSite.WebHome'))
3 +{{html clean="false"}}
4 +
5 + <section class="resource-header" aria-labelledby="hero-title">
6 + <div class="container">
7 + <div class="text-center">
8 + <div class="hero-kicker">
9 + <i class="fa fa-shield" aria-hidden="true"></i>
10 + XWiki security review
11 + </div>
12 + </div>
13 +
14 + <h1 id="hero-title">What an XWiki security review should actually include</h1>
15 +
16 + <p class="resource-summary">
17 + A working XWiki instance is not automatically a secure one. A proper review should look at versions,
18 + access rights, authentication, extensions, custom code, infrastructure and operational practices.
19 + </p>
20 + </div>
21 + </section>
22 +
23 + <section class="resource-page">
24 + <div class="container">
25 + <div class="resource-layout">
26 +
27 + <aside class="resource-sidebar" aria-label="Page summary">
28 + <h4>In this guide</h4>
29 + <ul>
30 + <li><a href="#why-it-matters">Why it matters</a></li>
31 + <li><a href="#what-to-review">What to review</a></li>
32 + <li><a href="#security-checklist">Security checklist</a></li>
33 + <li><a href="#review-output">What the review should produce</a></li>
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 + </ul>
37 + </aside>
38 +
39 + <article class="resource-content">
40 +
41 + <p>
42 + Many XWiki instances continue to work well from a user perspective while slowly accumulating security
43 + and governance risks. Users can still log in, search, edit pages and access documents, but that does not
44 + always mean the instance is properly secured or easy to maintain.
45 + </p>
46 +
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 + Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
54 + forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
55 + weak fallback access or backup assumptions that were never tested.
56 + </p>
57 +
58 + <div class="resource-note">
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 + <strong>The main point:</strong> an XWiki security review should not only check whether the application
76 + is online. It should evaluate the platform, the access model and the operational practices around it.
77 + </p>
78 + </div>
79 +
80 + <h2 id="why-it-matters">Why an XWiki security review matters</h2>
81 +
82 + <p>
83 + XWiki is often used as an internal knowledge base, intranet, documentation platform or controlled
84 + document system. In these cases, the platform may contain sensitive procedures, internal decisions,
85 + customer information, technical documentation, compliance records or business-critical workflows.
86 + </p>
87 +
88 + <p>
89 + The more important the content becomes, the more important it is to understand who can access it, who can
90 + change it, which customizations influence it and how safely the instance can be upgraded or restored.
91 + </p>
92 +
93 + <p>
94 + A security review helps identify risks before they become incidents, upgrade blockers or maintenance
95 + surprises. It also gives administrators a clearer view of the current state of the instance.
96 + </p>
97 +
98 + <h2 id="what-to-review">What should be reviewed</h2>
99 +
100 + <h3>1. Version and upgrade status</h3>
101 + <p>
102 + The current XWiki version should be reviewed together with the target upgrade path, installed extensions
103 + and infrastructure dependencies. An outdated instance is not only a maintenance concern. It can also mean
104 + that security fixes, compatibility improvements and platform hardening are missing.
105 + </p>
106 +
107 + <p>
108 + The review should also check whether upgrades are performed regularly or only when something breaks.
109 + A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
110 + </p>
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 + <h3>2. Access rights and permission model</h3>
118 + <p>
119 + XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
120 + should check who has administration rights, who has script or programming rights, whether rights are
121 + assigned through groups, and whether page-level exceptions are still understandable.
122 + </p>
123 +
124 + <p>
125 + It is also important to review inherited rights, public areas, restricted spaces, old groups, inactive
126 + users and sensitive pages. Many permission problems do not come from one obvious mistake, but from years
127 + of small exceptions that nobody reviewed later.
128 + </p>
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 + <h3>3. Authentication and identity management</h3>
138 + <p>
139 + Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
140 + Directory, OIDC, SAML, SSO and MFA setups all need to be checked together with group synchronization,
141 + fallback login options, local administrator accounts and recovery procedures.
142 + </p>
143 +
144 + <p>
145 + SSO is useful, but it does not automatically guarantee a clean access model. Authentication confirms who
146 + the user is. Authorization still depends on how XWiki groups and rights are configured.
147 + </p>
148 +
149 + <h3>4. Extensions and custom code</h3>
150 + <p>
151 + Installed extensions, custom applications, Velocity scripts, Groovy scripts, macros, sheets, templates,
152 + UI extensions and Java components are all part of the security and maintenance surface of the instance.
153 + </p>
154 +
155 + <p>
156 + A review should identify what is installed, what is customized, what is still used, what is documented and
157 + what needs special validation during upgrades. Custom code should be tracked, explained and tested, not
158 + discovered accidentally during an incident or a production upgrade.
159 + </p>
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 + <h3>5. Configuration, infrastructure and operations</h3>
167 + <p>
168 + The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
169 + access, filesystem and attachment storage, mail configuration, PDF export services, logs, monitoring,
170 + server access and separation between production and staging.
171 + </p>
172 +
173 + <p>
174 + Backups should be reviewed together with restore expectations. A backup strategy is incomplete if nobody
175 + knows what is included, how long recovery would take or whether the restore process has ever been tested.
176 + </p>
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-default" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
185 + </div>
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 + <ul class="resource-checklist">
195 + <li>Check the current XWiki version, target version and upgrade path.</li>
196 + <li>Review installed extensions, outdated components and unsupported customizations.</li>
197 + <li>Audit administrator, script and programming rights.</li>
198 + <li>Review groups, inherited permissions and page-level exceptions.</li>
199 + <li>Validate authentication, SSO, MFA, fallback access and administrator recovery options.</li>
200 + <li>Identify custom scripts, templates, macros, UI extensions and Java components.</li>
201 + <li>Review public, internal and restricted areas.</li>
202 + <li>Check infrastructure, HTTPS, reverse proxy, database, filesystem and mail configuration.</li>
203 + <li>Confirm backup coverage, restore expectations and rollback procedures.</li>
204 + <li>Document findings and prioritize remediation actions.</li>
205 + </ul>
206 +
207 + <h2 id="review-output">What the review should produce</h2>
208 +
209 + <p>
210 + A useful security review should not only produce a list of detected problems. It should produce a practical action
211 + plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
212 + </p>
213 +
214 + <p>
215 + Some findings may require immediate action, such as exposed administration rights or unsafe fallback
216 + access. Others may become planned improvements, such as cleaning old groups, documenting custom code,
217 + reviewing extensions or preparing the next upgrade.
218 + </p>
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 + <p>
229 + The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
230 + understand the access model, critical features are documented and future upgrades can be planned with
231 + fewer surprises.
232 + </p>
233 +
234 + <h2 id="when-to-review">When should an XWiki security review be done?</h2>
235 +
236 + <p>
237 + A review is especially useful before a major upgrade, after years of organic growth, after an authentication
238 + change, before exposing the instance more broadly, after a migration, or when the wiki becomes more
239 + business-critical than it was when first installed.
240 + </p>
241 +
242 + <p>
243 + It is also useful when administration responsibilities change. A new team should not have to guess how
244 + permissions, extensions, customizations and recovery procedures were configured years earlier.
245 + </p>
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 + <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 + <div class="resource-cta">
331 + <h3>Need an XWiki security review?</h3>
332 + <p>
333 + If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
334 + SSO, extensions and business-critical workflows, a structured review can help identify risks and define
335 + the safest next steps.
336 + </p>
337 + <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
338 + </div>
339 +
340 + </article>
341 +
342 + </div>
343 + </div>
344 + </section>
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 +{{/html}}
396 +{{/velocity}}
xwiki-security-review.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.Admin
Size
... ... @@ -1,0 +1,1 @@
1 +1.3 MB
Content
Agnease.Code.SEODetailsClass[0]
metaDescription
... ... @@ -1,0 +1,1 @@
1 +Learn what an XWiki security review should include: version status, access rights, authentication, extensions, custom code, infrastructure, backups and operational practices.
metaTitle
... ... @@ -1,0 +1,1 @@
1 +What an XWiki Security Review Should Actually Include | Agnease