Skip to Content
Last modified by Agnease on 2026/05/26 15:27
From version 1.9
edited by Agnease
on 2026/05/26 10:48
Change comment: There is no comment for this version
To version 1.3
edited by Agnease
on 2026/05/26 07:46
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
... ... @@ -146,11 +146,6 @@
146 146   discovered accidentally during an incident or a production upgrade.
147 147   </p>
148 148  
149 - <p>
150 - Customizations should also be reviewed from a maintenance perspective. See
151 - <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
152 - </p>
153 -
154 154   <h3>5. Configuration, infrastructure and operations</h3>
155 155   <p>
156 156   The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
... ... @@ -163,22 +163,8 @@
163 163   knows what is included, how long recovery would take or whether the restore process has ever been tested.
164 164   </p>
165 165  
166 - <div class="resource-inline-cta">
167 - <p>
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.
171 - </p>
172 - <a class="btn btn-secondary" href="$xwiki.getURL('contact.WebHome')">Request a quick review</a>
173 - </div>
140 + <h2 id="security-checklist">Practical XWiki security review checklist</h2>
174 174  
175 - <h2 id="security-checklist">XWiki security review checklist</h2>
176 -
177 - <p>
178 - A practical XWiki security review should cover both application-level and operational risks.
179 - The following checklist can be used as a starting point when reviewing a production instance.
180 - </p>
181 -
182 182   <ul class="resource-checklist">
183 183   <li>Check the current XWiki version, target version and upgrade path.</li>
184 184   <li>Review installed extensions, outdated components and unsupported customizations.</li>
... ... @@ -195,7 +195,7 @@
195 195   <h2 id="review-output">What the review should produce</h2>
196 196  
197 197   <p>
198 - A useful security review should not only produce a list of detected problems. It should produce a practical action
158 + A useful security review should not only produce a list of problems. It should produce a practical action
199 199   plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
200 200   </p>
201 201  
... ... @@ -205,14 +205,6 @@
205 205   reviewing extensions or preparing the next upgrade.
206 206   </p>
207 207  
208 - <div class="resource-note">
209 - <p>
210 - <strong>A useful review should separate findings by priority:</strong> immediate risks,
211 - planned remediation, maintenance improvements and documentation gaps. This makes the result
212 - easier to act on instead of producing a generic list of observations.
213 - </p>
214 - </div>
215 -
216 216   <p>
217 217   The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
218 218   understand the access model, critical features are documented and future upgrades can be planned with
... ... @@ -232,42 +232,6 @@
232 232   permissions, extensions, customizations and recovery procedures were configured years earlier.
233 233   </p>
234 234  
235 - <h2 id="security-review-faq">XWiki security review FAQ</h2>
236 -
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>
243 -
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>
250 -
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>
256 -
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>
263 -
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 271   <div class="resource-note">
272 272   <p>
273 273   Related resources:
... ... @@ -293,54 +293,5 @@
293 293   </div>
294 294   </section>
295 295  
296 - <script type="application/ld+json">
297 - {
298 - "@context": "https://schema.org",
299 - "@type": "FAQPage",
300 - "mainEntity": [
301 - {
302 - "@type": "Question",
303 - "name": "What should an XWiki security review include?",
304 - "acceptedAnswer": {
305 - "@type": "Answer",
306 - "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."
307 - }
308 - },
309 - {
310 - "@type": "Question",
311 - "name": "Is an updated XWiki instance automatically secure?",
312 - "acceptedAnswer": {
313 - "@type": "Answer",
314 - "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."
315 - }
316 - },
317 - {
318 - "@type": "Question",
319 - "name": "Does SSO solve XWiki access control?",
320 - "acceptedAnswer": {
321 - "@type": "Answer",
322 - "text": "No. SSO helps authenticate users, but access control still depends on XWiki groups, inherited permissions, page-level rights and administrative privileges."
323 - }
324 - },
325 - {
326 - "@type": "Question",
327 - "name": "Why should custom code be reviewed in XWiki?",
328 - "acceptedAnswer": {
329 - "@type": "Answer",
330 - "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."
331 - }
332 - },
333 - {
334 - "@type": "Question",
335 - "name": "When should an XWiki security review be done?",
336 - "acceptedAnswer": {
337 - "@type": "Answer",
338 - "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."
339 - }
340 - }
341 - ]
342 - }
343 - </script>
344 -
345 345  {{/html}}
346 346  {{/velocity}}
Agnease.Code.SEODetailsClass[0]
metaDescription
... ... @@ -1,1 +1,0 @@
1 -Learn what an XWiki security review should include: version status, access rights, authentication, extensions, custom code, infrastructure, backups and operational practices.
metaTitle
... ... @@ -1,1 +1,0 @@
1 -What an XWiki Security Review Should Actually Include | Agnease