Sitecore security checklist

You're reading the latest version of the Sitecore security checklist. Last revision date: 27 January, 2026

Important

As part of preparing to submit your public app for approval from Sitecore, you must review the Sitecore security checklist and ensure your app complies with it. Then, confirm compliance on the Submission details tab when finishing app configuration.

To support trust, transparency, and security in the Sitecore Marketplace, this document sets out the security checklist that developers must complete when submitting applications for the Sitecore Marketplace. Developers are responsible for ensuring their applications conform to these requirements. Sitecore may request this checklist or supporting documentation at any time to validate compliance or investigate reported issues.

All contributions must be approved by Sitecore before being listed. Sitecore may request additional verification steps at its discretion, including, but not limited to, static code analysis, security testing and validation, or other reviews, and reserves the right to update, revise, or add to these requirements over time.

How to use this checklist

  • Review and complete each item in the checklist and retain evidence.

  • By submitting your application, you attest that all checked items are met.

  • Sitecore may request supporting evidence (for example: documentation, test results, SBOM, third-party audit reports).

  • In the event of a security incident or investigation, developer must be prepared to provide such evidence.

Sitecore reserves the right to revise, change, add, or remove any security standards and protocols.

Marketplace application security checklist

While no one checklist will cover all requirements, this checklist represents the minimal set of requirements for security maturity and deployment in the Sitecore Marketplace. Sitecore reserves the right to reasonably revise, change, add, or remove any requirements including security standards and protocols, in this checklist.

Developer attests to compliance with this checklist and agrees to provide such supporting documentation as may be reasonably requested by Sitecore to ensure compliance.

Source Code

  • Developer must maintain an escrow-ready copy of all application versions, identified by version/release number, to support investigations or rollback as required.

Data Protection

Regulatory Compliance

  • Developer must have a Privacy Policy.

  • Developer must maintain a Data Processing Addendum that complies with GDPR requirements.

  • Developer must maintain a Data Subject Access Request process applicable to all Personal Data processed by the developer’s application.

Data Inventory

  • Developer must maintain an accurate and up-to-date inventory of all data processed by developer’s application.

Data at Rest

  • All developer controlled data stored by the application (except data at the user’s browser) must have underlying full-disk encryption.

    • Where possible, full-disk encryption should use FIPS 140-2 encryption.

Data in Transit

  • Applications must use TLS version 1.2 (or higher) with strong cipher suites to encrypt traffic over public or untrusted networks.

  • Applications must enable HSTS with a minimum age of one year.

  • Applications should comply with Mozilla’s Service Security TLS guidance.

Secrets

  • Secrets must not be stored in easily accessed locations, such as source code, headers/URL strings, configuration files, or application logs.

Application Security

Secure Development Environment

  • Applications hosted by the developer must be managed in a secured environment.

  • Access to developer’s secure development environment must be secured, managed to RBAC and Least Privilege principles.

  • Developer must follow secure coding practices such as OWASP Top 10, OWASP ASVS or similar.

Application

  • Developer’s applications may not use unsupported Sitecore APIs and SDKs.

  • All application endpoints must be stable and documented, with documentation available to share based on a request from Sitecore or a customer.

  • Applications must enable security headers and cookie security attributes, following OWASP guidance.

  • Applications must validate and sanitize all untrusted data to mitigate injection-related vulnerabilities.

    • Applications must treat all user input as unsafe.

  • Sensitive actions are verified and protected from client-side tampering or forgery.

  • Applications must enforce strict isolation of tenant data. Sitecore may request evidence of third-party penetration testing to confirm isolation.

Authentication and Authorization

  • An application must authenticate and authorize every request on all Sitecore endpoints exposed.

    • Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.

  • Hard-coded tokens must not be used.

  • Tokens must be scoped to the user making the request.

Logging

  • Applications must log authentication events, access control decisions, and sensitive operations to a contributor controlled secure log store.

  • Logs must follow a common log format (CLF, ELF) and content.

    • All timestamps must be in UTC format.

  • Logs must be securely stored in a tamperproof format (such as a WORM drive or controlled location).

  • Logs must be made available when reasonably requested in support of troubleshooting or investigation.

Third-Party and Open Source Software

  • All third-party libraries included or leveraged by the application, including open source, originate from reputable sources and be actively maintained.

  • Applications must not use (version of) third-party libraries and dependencies with known critical or high vulnerabilities.

  • Use of AGPL, GPL and other copy-left third-party libraries by third-party libraries included with the contribution, or by the contribution itself is strictly prohibited.

  • Developer must maintain an accurate and up-to-date SBOM for each application.

    • Developer must be prepared to provide to Sitecore on reasonable request.

Security Testing

  • Applications must be tested and free of common vulnerabilities such as OWASP Top 10, SANS 25 and other common or emergent vulnerability classes.

  • Applications may not be released until all critical findings have been remediated, including findings against included open source or third-party code.

    • Developer may not downgrade a finding more than one level (a critical vulnerability may not be downgraded to moderate severity).

Vulnerability Management

  • Developer must maintain a discipline to monitor and remediate critical and high vulnerabilities and provide patches or application updates (as appropriate) to customers as quickly as possible.

  • If developer is unable to remediate a critical vulnerability within documented SLA, developer must notify Sitecore immediately and must remove the Application from the Marketplace.

    • Sitecore reserves the right to remove applications at any time.

AI Usage

Data Security & Privacy

  • Data provenance - training data is sourced ethically and legally, with proper documentation.

  • PII protection - personally identifiable information is not used as part of training data.

  • Data minimization - only collect and process data necessary for the AI functionality.

Model Security

  • Model robustness - application includes defenses against adversarial attacks (for exampleinput manipulation).

  • Model integrity - developer ensures models are protected from tampering during deployment and updates.

  • Model explainability - developer provides transparency into how decisions are made, especially for high-risk use cases and includes this as part of application documentation.

Supply Chain & Dependencies

  • Third-party libraries - all AI/ML libraries and frameworks are reviewed for known vulnerabilities.

  • Model sourcing - when using pre-trained models, developer verifies model origin and ensures they are free from backdoors or malicious code.

Deployment & Runtime Security

  • Secure APIs - AI endpoints include rate limiting, and input validation protections.

  • Isolation - AI components are run in sandboxed environments to limit blast radius of compromise.

  • Monitoring - AI interactions are logged and monitored for anomalies or abuse, either by the developer or the underlying AI system provider; developer clearly explains how monitoring for anomalies and abuse is conducted.

Ethical & Responsible AI Use

  • Bias mitigation - developer tests models for bias and documents mitigation strategies.

  • Usage boundaries - developer clearly defines and enforces acceptable use policies for AI features.

  • Human oversight - developer ensures critical decisions made by AI are reviewable by humans.

Compliance & Governance

  • Internal governance - developer must have an AI policy and governance structure that ensures the safe, responsible, and ethical use of AI.

  • Regulatory alignment - developer ensures all included AI systems comply with relevant laws (for example: GDPR, HIPAA, EU AI Act).

  • Auditability - developer maintains logs and documentation for audits and incident investigations.

  • Security reviews - developer performs regular security assessments of AI components.

Incident Response

  • Model rollback - developer has procedures to revert to safe versions of models in case of compromise.

  • Threat intelligence - developer monitors for emerging AI threats and vulnerabilities and ensures application has appropriate protections.

  • Disclosure policy - developer maintains responsible disclosure of AI-related vulnerabilities in its application.

Security Incidents

Checklist

  • Developer must immediately, and no later than 72 hours after confirmation of incident, notify Sitecore of all security incidents related to use of application through [email protected].

  • Developer must identify at least one email as a security contact; it is strongly recommended that this be a monitored email alias to ensure immediate action in case of a security incident.

Contractual Obligations

  • Developer must maintain an incident response plan that is practiced at least annually covering cybersecurity incidents, including 0-day vulnerabilities, resulting from the developer’s application(s).

  • Developer retains responsibility for notifying all customers of the developer’s application of a cybersecurity incident including data breach, no later than 72 hours after confirmation of incident.

  • Developer must notify Sitecore and application customers of presence of 0-day vulnerability in the Application no later than 24 hours after confirmation of 0-day vulnerability.

Do you have some feedback for us?

If you have suggestions for improving this article,