Penetration tests of an Exponential site
This page is for project managers and security officers who commission a penetration test, and for administrators who prepare the installation. A good test of an Exponential site focuses on what is yours (design, extensions, configuration, hosting) and reports findings in the product to the project.
Note This page describes features and common practice; it is not legal advice. Check the law that applies to your organization with your legal counsel.
Contents
- Scope
- What to give the testers
- Preparing the installation
- During the test
- Handling findings
- Related pages
Scope
- Environment: a staging copy with the same version, extensions, designs and web server configuration is the safest target; testing production needs written approval and a time window.
- Targets: the public siteaccesses, the administration siteaccess, the REST API if enabled (REST API v1 and v2), forms, file uploads, sign-in and two-step sign-in.
- Out of scope: third-party services your extensions call (analytics, CAPTCHA, maps, AI providers) unless their owners agree.
What to give the testers
| Item | Source |
|---|---|
| Versions | composer show se7enxweb/exponential, Setup > System information |
| Activated extensions | Setup > Extensions |
| Siteaccesses and host names | your configuration |
| Test accounts, one per role (anonymous, member, editor, publisher, administrator) | created for the test, disabled afterwards |
| Known gaps and accepted risks | Security standards: Known gaps and your risk register |
| The security settings in force | password policy, lockout, CSP mode, HSTS |
Giving testers the known gaps (for example "lockout off by design, decision recorded") saves time and focuses the report on what is new.
Preparing the installation
- Run the file consistency check so the test starts from a known state.
- Decide what to do with request-shield: leave it in front to test the real setup, or put it in monitor mode so the testers reach the application; record the choice.
- Tell the alert recipients: audit alerts (brute force, role granted) will fire.
- Back up the staging database and
var/storage. - If lockout is on, add the testers' addresses to
TrustedIPList[]only if you want to exclude lockout from the test.
During the test
- The audit trail records sign-ins, refusals and changes;
security.logrecords probes. Both help you reconcile the testers' activity with what your monitoring saw: a useful detection exercise in itself. - Every admin response carries
X-Exp-Request-Id; testers can quote it so you find the exact records (/audit/console/(request)/<id>).
Handling findings
| Finding in | Do |
|---|---|
| Your design, templates or extensions | fix, retest |
| Configuration or hosting | fix per the hardening pages, retest |
| Exponential itself or a shipped extension | report privately to [email protected] (see "Vulnerability disclosure"); do not publish before a fix is released |
After the test: disable the test accounts, remove test content, put request-shield back to enforce, and keep the report with your security documentation.
Related pages
- Security hardening
- Vulnerability disclosure
- The audit trail for public bodies
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.