Security Hardening for SAP Commerce: The Application-Layer Checklist Pen Testers Start With

On CCv2, SAP hardens the infrastructure: the OS, the web tier, the network, the patching cadence. What SAP cannot harden is your application: your custom endpoints, your Spring Security rules, your extension list, your password policy, your CORS configuration. That is the attack surface a penetration tester actually probes, because it is the only surface your specific project created, and it is the surface where breaches happen. This guide is the application-layer hardening checklist, consolidated from the platform-security material across the CX Works infrastructure and data-protection sources, scoped to what applies regardless of where you host. The on-premise infrastructure guide covers the additional web-tier and OS hardening for self-hosted estates; the data protection guide covers the GDPR obligations that intersect here.

Identity and Password Storage#

• Strong password encoding, verified by query. Modern platforms default to strong encodings, but migrated users and legacy configuration hide weak ones. Sweep for them, in hAC:

SELECT {uid}, {passwordEncoding} FROM {User}
WHERE {passwordEncoding} NOT IN ('pbkdf2', 'sha256', 'sha512', 'argon2')

Anything returned is a remediation item; re-encode via the platform's password mechanisms and confirm the default (pbkdf2 or stronger) is set project-wide. Never store or transmit passwords in clear text, and treat any legacy flow that does (the source's cautionary tale of passwords phoned to users) as a finding.

• Transparent Attribute Encryption primary password. TAE encrypts sensitive attributes (including hashed passwords) and its primary password cannot be rotated after the fact, only its keys can. Therefore change it, and generate a non-default key, before the first user is created on every environment. Discovering a default TAE key in production is the kind of finding that has no cheap remediation.

• Media storage hash salt. Change media.default.storage.location.hash.salt early, before media exists, so secure-media URLs are not guessable from a known default.

The Initialization Lock#

One property prevents one of the most catastrophic operator errors in the platform:

system.unlocking.disabled=true

Set on every environment above development. It disables the initialize/update buttons, and an unlocked production initialize has erased live estates. It is a single line; there is no excuse for its absence, and its presence belongs in your deployment verification.

Cockpit, Backoffice, and Admin Access#

• Disable default cockpit/hMC credentials on any version that still ships them (empty the *.default.login / *.default.password properties).
• Employees in Backoffice, customers on the storefront, enforced. The platform's pre-authentication checks restrict cockpit access to employee groups since 5.0; verify the beans are in place and not overridden, and that no customer group has leaked cockpit access.
• Reset default accounts (except admin) to your encoding via ImpEx, re-checked after every system update, because updates can revert them.
• Admin endpoints off the public internet. The endpoint matrix from the web architecture guide is a security control: Backoffice, hAC, Solr admin behind IP filter sets or private endpoints, never publicly reachable. Test the restriction against host-header spoofing.
• Break-glass administration: one vaulted emergency admin outside any SSO dependency, with alerting on its use (the SSO guide's point), so an identity-provider outage cannot lock every human out of Backoffice.

Web-Facing Application Configuration#

• CORS locked down. Configure allowed origins explicitly to your known storefront and API domains; a permissive * on an authenticated API is an invitation. Review the OCC CORS configuration against the actual domain list.
• Cookies hardened: HttpOnly on session cookies, Secure everywhere, SameSite chosen deliberately (the 2FA/session guide's settings). Verify in the browser, not just the config.
• Secure pages actually secure. Since the accelerator era, account and checkout pages default to HTTPS-only; review the Spring Security configuration to confirm the access rules match reality, especially after storefront customization that may have loosened them.
• Anonymous login disabled in core (login.anonymous.always.disabled=true), confirmed not overridden in project properties, so the anonymous customer can never authenticate.
• Custom error pages that reveal nothing (no stack traces, no version banners); the application handles 500/404 rather than leaking the container's defaults.

The Extension Attack Surface#

Every loaded extension and web module is surface area:

• Audit loaded web modules in hAC (Platform > Extensions, sort by webroot). Justify each one; extensions frequently ship web modules you never intended to expose, and the fix is removing the web entry from extensioninfo.xml, not the webroot-disable trick that breaks hAC clusterwide.
• Remove risky and unused extensions. VJDBC is the canonical example (a database-over-HTTP bridge with no place in production); more generally, disable what you do not use, because an unused extension is unpatched surface.
• Custom OCC endpoints and controllers are your code and your risk: authorization checks on every endpoint (not just authentication), input validation, no mass-assignment of model attributes from request bodies, and rate limiting on anything expensive or enumerable. These are the endpoints the pen test hammers precisely because they are unique to you.

Spring Security and Authorization#

• Review the security configuration as a deliberate artifact, not inherited defaults: URL access rules, method-level security on services that need it, and the mapping between authenticated identity and commerce authorization (the user management and B2B identity guides).
• Authorization is not authentication. A logged-in user reaching another user's order by changing an ID in the URL is the classic broken-object-level-authorization bug (OWASP's number one for APIs), and it passes every authentication check. Every endpoint that takes an object reference must verify the caller owns or may access that object.
• Keep authorization mastered in commerce groups/permissions and authentication in the identity layer; splitting them the other way produces the two-systems-disagree gaps attackers probe for.

The OWASP Lens and the Independent Test#

Secure your customizations against the OWASP Top 10 as an explicit exercise: injection (FlexibleSearch is parameterized for a reason, per the FlexibleSearch guide; never concatenate user input into queries), broken access control (above), cryptographic failures (TAE keys, TLS everywhere), security misconfiguration (the whole of this checklist), vulnerable components (the extension audit plus the platform's own patch level, and the update-release cadence from the upgrade guides is a security cadence). Then the non-negotiable: a penetration test by someone who did not build the site, against the release candidate, before go-live, with findings triaged into the go/no-go. Your customizations are the surface the platform's own testing has never seen, and the go-live guide treats this as a launch gate for exactly that reason.

The Hardening Checklist#

• Password encodings swept; all strong; clear-text flows eliminated
• TAE primary password and key changed before first user, per environment
• Media hash salt changed before media exists
• system.unlocking.disabled=true above dev, in deployment verification
• Default cockpit credentials emptied; default accounts reset post-update; cockpit access limited to employees
• Admin endpoints private/IP-filtered; host-header spoofing tested; break-glass admin vaulted and alarmed
• CORS restricted to known domains; cookies HttpOnly/Secure/SameSite; secure-page rules reviewed; anonymous login disabled
• Web module audit done; VJDBC and unused extensions removed; custom endpoints authorization-checked and input-validated
• Object-level authorization verified on every endpoint taking an ID
• OWASP Top 10 review completed; independent pen test against the release candidate with findings gated into go/no-go

Infrastructure security is increasingly a solved, outsourced problem on CCv2. Application security never will be, because your application is unique by definition. This checklist is the part that stays yours no matter who runs the servers, and every line on it earned its place in someone's incident report.