Evaluating security evidence in a CMS bid
This page is for the information security officer on an evaluation panel. It shows what the Exponential
documentation evidences, which defaults a public site should change, what is missing, and what to demand from the
bidder and the host. The facts come from Security standards,
Security hardening and SECURITY.md in the repository root.
Contents
- Three layers to evaluate
- What the product documentation evidences
- Defaults to check in the bid
- What is not evidenced
- What to demand from the bidder and the host
- Tests in the proof of concept
Three layers to evaluate
| Layer | Responsible | Evidence |
|---|---|---|
| The software | the project, through releases | Security standards |
| The configuration and custom code | the bidder | its hardening plan and code review |
| The hosting | the host (internal or external) | its operating procedures (Hosting security) |
What the product documentation evidences
| Area | Status | In short |
|---|---|---|
| OWASP Top 10 (2021) | Partly complies | mitigations named per category, three documented hardening passes |
| OWASP ASVS 4.0.3 | Unverified | no assessment; many level 1 controls exist |
| Content Security Policy Level 3 | Partly complies | per-request nonces and reporting; report-only on administration, none on sites by default |
| Logging and monitoring (A09) | Complies | tamper-evident audit trail on by default, alert rules, security log (Audit trail) |
| Coordinated disclosure | Partly complies | private reporting in SECURITY.md; no security.txt shipped |
Further facts an evaluator can rely on: passwords are stored with PHP's password_hash(), every form carries a CSRF
token, security headers are sent on every page, and published release tags are never changed
(Source control and releases).
Defaults to check in the bid
| Default | As shipped | What a public site usually needs |
|---|---|---|
| Account lockout | off (MaxNumberOfFailedLogin=0) | a decision: lockout, or rate limiting in front (request-shield) |
| Two-step sign-in | opt-in extension | on for every administrator and editor (Two-step sign-in) |
| Minimum password length | 10 | 12 or more if you follow ASVS level 1 (V2.1.1) |
| HSTS | empty | set once the whole site is HTTPS-only |
| Content Security Policy | report-only on admin, none on sites | enforce where the design allows (Content Security Policy) |
security.txt | not shipped | publish one following RFC 9116 |
Ask the bidder to state each of these settings for your site in the bid.
What is not evidenced
- No external penetration test or security audit is published for the product.
- No OWASP ASVS assessment (OWASP ASVS).
- No dependency vulnerability scan in CI;
composer auditis recommended in the hardening guide. - No prepared statements in the database layer; escaping is used, and extension code must follow the same rule.
- Output escaping in templates is not automatic.
- Commits and tags are not signed.
- The project publishes no service level agreement; the one response commitment is a first answer to a private
security report within one business day (
SECURITY.md).
What to demand from the bidder and the host
- A hardening plan based on chapter 13 of the installation book and the hardening checklist, with each item marked done or not.
- A code review or test of the bidder's own templates and extensions (escaping with
wash, SQL escaping). - A penetration test of the delivered site before go-live, by a party you accept.
- A patch commitment: apply released Exponential security fixes within a time you set, and PHP and operating system updates within a time you set (SLA options).
- Incident handling: who is called, how fast, and how the audit trail is preserved (Compromised site runbook).
- A mapping to your own framework, for example the NIST Cybersecurity Framework 2.0 or ISO/IEC 27001, if your policy requires one. The project provides none.
Tests in the proof of concept
- Sign in with a wrong password several times and look for the audit entries.
- Run
./console exp:audit verifyto check the audit chain. - Set up two-step sign-in for a test account.
- Read the response headers of a page (
X-Content-Type-Options,X-Frame-Options,Referrer-Policy). - Run Setup > Upgrade check to see the file consistency check.
Related pages
- Evaluation: overview
- Procurement: overview
- Security standards
- Security and audit guide
- 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.