Skip to Content
Version 1.3 by Agnease on 2026/05/26 07:46
Hide last authors
Agnease 1.2 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 </ul>
36 </aside>
37
38 <article class="resource-content">
39
40 <p>
41 Many XWiki instances continue to work well from a user perspective while slowly accumulating security
42 and governance risks. Users can still log in, search, edit pages and access documents, but that does not
43 always mean the instance is properly secured or easy to maintain.
44 </p>
45
46 <p>
47 Security risks are often hidden in less visible areas: outdated versions, inherited permissions,
48 forgotten administrator accounts, overly powerful rights, old extensions, undocumented scripts,
49 weak fallback access or backup assumptions that were never tested.
50 </p>
51
52 <div class="resource-note">
53 <p>
54 <strong>The main point:</strong> an XWiki security review should not only check whether the application
55 is online. It should evaluate the platform, the access model and the operational practices around it.
56 </p>
57 </div>
58
59 <h2 id="why-it-matters">Why an XWiki security review matters</h2>
60
61 <p>
62 XWiki is often used as an internal knowledge base, intranet, documentation platform or controlled
63 document system. In these cases, the platform may contain sensitive procedures, internal decisions,
64 customer information, technical documentation, compliance records or business-critical workflows.
65 </p>
66
67 <p>
68 The more important the content becomes, the more important it is to understand who can access it, who can
69 change it, which customizations influence it and how safely the instance can be upgraded or restored.
70 </p>
71
72 <p>
73 A security review helps identify risks before they become incidents, upgrade blockers or maintenance
74 surprises. It also gives administrators a clearer view of the current state of the instance.
75 </p>
76
77 <h2 id="what-to-review">What should be reviewed</h2>
78
79 <h3>1. Version and upgrade status</h3>
80 <p>
81 The current XWiki version should be reviewed together with the target upgrade path, installed extensions
82 and infrastructure dependencies. An outdated instance is not only a maintenance concern. It can also mean
83 that security fixes, compatibility improvements and platform hardening are missing.
84 </p>
85
86 <p>
87 The review should also check whether upgrades are performed regularly or only when something breaks.
88 A repeatable upgrade process is part of the security posture of a long-running XWiki instance.
89 </p>
90
91 <h3>2. Access rights and permission model</h3>
92 <p>
93 XWiki has a powerful access-rights system, but this flexibility needs a clear governance model. A review
94 should check who has administration rights, who has script or programming rights, whether rights are
95 assigned through groups, and whether page-level exceptions are still understandable.
96 </p>
97
98 <p>
99 It is also important to review inherited rights, public areas, restricted spaces, old groups, inactive
100 users and sensitive pages. Many permission problems do not come from one obvious mistake, but from years
101 of small exceptions that nobody reviewed later.
102 </p>
103
104 <h3>3. Authentication and identity management</h3>
105 <p>
106 Authentication should be reviewed beyond the simple question of whether users can log in. LDAP, Active
107 Directory, OIDC, SAML, SSO and MFA setups all need to be checked together with group synchronization,
108 fallback login options, local administrator accounts and recovery procedures.
109 </p>
110
111 <p>
112 SSO is useful, but it does not automatically guarantee a clean access model. Authentication confirms who
113 the user is. Authorization still depends on how XWiki groups and rights are configured.
114 </p>
115
116 <h3>4. Extensions and custom code</h3>
117 <p>
118 Installed extensions, custom applications, Velocity scripts, Groovy scripts, macros, sheets, templates,
119 UI extensions and Java components are all part of the security and maintenance surface of the instance.
120 </p>
121
122 <p>
123 A review should identify what is installed, what is customized, what is still used, what is documented and
124 what needs special validation during upgrades. Custom code should be tracked, explained and tested, not
125 discovered accidentally during an incident or a production upgrade.
126 </p>
127
128 <h3>5. Configuration, infrastructure and operations</h3>
129 <p>
130 The review should also cover the environment around XWiki: HTTPS and reverse proxy configuration, database
131 access, filesystem and attachment storage, mail configuration, PDF export services, logs, monitoring,
132 server access and separation between production and staging.
133 </p>
134
135 <p>
136 Backups should be reviewed together with restore expectations. A backup strategy is incomplete if nobody
137 knows what is included, how long recovery would take or whether the restore process has ever been tested.
138 </p>
139
140 <h2 id="security-checklist">Practical XWiki security review checklist</h2>
141
142 <ul class="resource-checklist">
143 <li>Check the current XWiki version, target version and upgrade path.</li>
144 <li>Review installed extensions, outdated components and unsupported customizations.</li>
145 <li>Audit administrator, script and programming rights.</li>
146 <li>Review groups, inherited permissions and page-level exceptions.</li>
147 <li>Validate authentication, SSO, MFA, fallback access and administrator recovery options.</li>
148 <li>Identify custom scripts, templates, macros, UI extensions and Java components.</li>
149 <li>Review public, internal and restricted areas.</li>
150 <li>Check infrastructure, HTTPS, reverse proxy, database, filesystem and mail configuration.</li>
151 <li>Confirm backup coverage, restore expectations and rollback procedures.</li>
152 <li>Document findings and prioritize remediation actions.</li>
153 </ul>
154
155 <h2 id="review-output">What the review should produce</h2>
156
157 <p>
158 A useful security review should not only produce a list of problems. It should produce a practical action
159 plan. Each finding should explain the risk, the affected area, the recommended action and the priority.
160 </p>
161
162 <p>
163 Some findings may require immediate action, such as exposed administration rights or unsafe fallback
164 access. Others may become planned improvements, such as cleaning old groups, documenting custom code,
165 reviewing extensions or preparing the next upgrade.
166 </p>
167
168 <p>
169 The best outcome is a clearer, safer and more maintainable XWiki instance: one where administrators
170 understand the access model, critical features are documented and future upgrades can be planned with
171 fewer surprises.
172 </p>
173
174 <h2 id="when-to-review">When should an XWiki security review be done?</h2>
175
176 <p>
177 A review is especially useful before a major upgrade, after years of organic growth, after an authentication
178 change, before exposing the instance more broadly, after a migration, or when the wiki becomes more
179 business-critical than it was when first installed.
180 </p>
181
182 <p>
183 It is also useful when administration responsibilities change. A new team should not have to guess how
184 permissions, extensions, customizations and recovery procedures were configured years earlier.
185 </p>
186
187 <div class="resource-note">
188 <p>
189 Related resources:
190 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
191 and
192 <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
193 </p>
194 </div>
195
196 <div class="resource-cta">
197 <h3>Need an XWiki security review?</h3>
198 <p>
199 If your XWiki instance has grown over time, contains sensitive content, uses custom code or depends on
200 SSO, extensions and business-critical workflows, a structured review can help identify risks and define
201 the safest next steps.
202 </p>
203 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request a security review</a>
204 </div>
205
206 </article>
207
208 </div>
209 </div>
210 </section>
211
212 {{/html}}
213 {{/velocity}}