¶ Admin panel and store security in Hummerce
Admin panel and store security in Hummerce is a set of mechanisms that protect the admin panel, customer accounts and store data from takeover, leaks and abuse. The mechanisms are part of the platform - they are turned on and configured per store, instead of building security from scratch for every implementation.
As of Hummerce 2.35 (latest security mechanism changes: 2.35.63), updated 2026-10-07.
¶ Benefits and use cases
- 2FA stops the most common store takeover scenario - a stolen or leaked admin password is not enough to get into the panel.
- Less risk of unauthorized orders and data changes - a stolen customer or admin session stops working.
- Lower risk of a GDPR breach - e-mail addresses and session identifiers don't leak into statistics, logs and links.
- Better results in audits and security scans commissioned by partners (e.g. banks, payment operators, corporate customers).
- Fast rollout - the mechanisms are part of the platform, so enabling them is usually a matter of hours, not a project built from zero.
- Team access control - change history and permissions let you determine who changed data and when, and restrict access for staff, agencies and subcontractors to what they need.
The platform is regularly hardened based on an independent security audit (penetration tests) and observation of automated attack attempts on stores - one set of safeguards for all Hummerce stores, instead of individual solutions per store. Which mechanisms are active in your store depends on its configuration and template - on request, we'll check this and enable any that are missing (see Implementation).
| Mechanism |
Protects |
| Two-factor login (2FA) |
admin panel |
| Admin permissions |
admin panel |
| Session protection |
admin panel, customer accounts |
| Form protection (CSRF) |
admin panel, store |
| Security headers |
store |
| Personal data kept out of page addresses |
customers |
| Input validation |
admin panel, store |
| Customer password strength |
customer accounts |
| reCAPTCHA |
store forms |
| Change history |
admin panel |
| Test store protection |
test environment |
| Encrypted connection (HTTPS) |
admin panel, store |
- After entering their login and password, the admin confirms the login with a second factor - without it, the password alone isn't enough to get into the panel.
- Two methods to choose from, one active on the account at a time:
- code via e-mail - a one-time code sent to the account's address, valid for a limited time; sending a new code invalidates the previous one,
- authenticator app (e.g. Google Authenticator, Microsoft Authenticator) - a code from the app, set up by scanning a QR code.
- Works on two levels: a global switch at the store level, and individual enabling and method selection on each admin's own account.
- Trusted browser - during verification, a browser can be remembered for a number of days set in the configuration. Remembering can be tied to the browser version, and an admin can revoke all trusted browsers on their account at any time.
- Lockout after failed codes - after a series of failed attempts, the account is temporarily locked. Another admin can lift the lock earlier.
- Session verification - the store remembers the browser and connection characteristics used to log into an account. If they change during the session in a way that suggests a takeover, the session is invalidated and the user must log in again. Separate switches for store customers and for panel admins.
- New session identifier after login and logout - the identifier assigned before login doesn't work after login.
- Session identifier only in a cookie - it doesn't appear in page addresses, so it doesn't end up in shared links, statistics (e.g. Google Analytics), server logs or search results.
- Idle timeout - a session in the store and in the panel expires after a period of inactivity. A different value is set as part of implementation work.
- Protects against a situation where an outside website tries to submit a form to the store on behalf of a logged-in customer or admin (e.g. changing data, placing an order, performing a panel operation).
- The store only accepts data-changing operations when they come from its own pages. Others are rejected.
- Covers store forms and panel operations. Separate switches for the store and for the panel.
- External services that send data to the store (e.g. payment gateway notifications, integrations) are accounted for in the protection configuration. The REST API has its own authentication.
- The store adds standard browser instructions to its pages that limit abuse on the customer side: forcing an encrypted (HTTPS) connection on subsequent visits, banning embedding store pages in frames on other sites, banning the browser from "guessing" file types, limiting the information passed to other sites in the referrer address, blocking store pages' access to the camera, microphone and location, and a content source policy (Content Security Policy).
- Values are chosen so as not to block Google Tag Manager or typical integrations. A policy tailored to a specific store's scripts is set up during implementation.
- The module is turned on and off in the panel, with no server configuration changes.
- Links generated by the store (including account confirmation, newsletter sign-up and unsubscribe, password reset) contain an identifier instead of an e-mail address. Links work the same as before.
- The e-mail address is not visible in the browser's address bar or in analytics tools.
Data sent to the store is checked before use. Fixes resulting from security audits go into subsequent releases and take effect after an update, with no configuration - which is why we recommend keeping the store on the latest version.
A minimum password level at registration (low, medium, high, or a custom rule) and a graphical password strength indicator in the form. We recommend setting at least the medium level.
Google reCAPTCHA v3 assesses user behavior in the background; the "I'm not a robot" test only appears on a suspicious result. Enabled per form.
Roles with access to selected menu items and views - an admin only sees what they're entitled to. The AI assistant (MCP) uses the same permissions as the panel account. Details: Admin permissions.
A record of changes in the store - admin logins, changes to orders, items, customers, configuration and other objects - with filtering and archiving. Details: Change history.
The store on the test environment is only accessible to people with an access link. All other visits (including search engine crawlers) are redirected to a designated address, e.g. the production store - the test version doesn't reach Google or customers. We provide the access link to the store's team during implementation. Reporting bugs directly from the store is described on the Maintenance mode page.
- The full package described on this page - since version 2.35. Older versions only have some of the mechanisms - we recommend updating to the latest release.
- Latest changes to the security mechanisms: version 2.35.63.
- Store version 2.35 for the full package (see Version).
- The Bootstrap 5 or Bootstrap 4 store template - form protection (CSRF) and the cookie-only session identifier are prepared in them. Older and custom templates need adjustment.
- An SSL certificate and the store running exclusively over HTTPS - a condition for forcing the encrypted connection.
- 2FA via e-mail - an e-mail address on the admin account and working mail sending from the store.
- 2FA via app - a phone with an authenticator app.
- reCAPTCHA - keys from the store's Google account.
- An SPF record for the store's mail domain (DNS) - makes it harder to spoof the store's address in e-mails.
- Works right after an update - input validation, an identifier instead of an e-mail address in links, permissions and history.
- Requires enabling and configuring per store - 2FA, session protection, form protection (CSRF), security headers, password strength and reCAPTCHA. Scope:
- reviewing which mechanisms are active in the store,
- enabling the 2FA module, setting parameters, testing login with an e-mail code and with the app, briefing admins on how to configure their accounts,
- enabling session verification and checking it against the store's traffic,
- enabling security headers and checking the store (analytics, payments, chats, widgets, embedded content),
- preparing CSRF form protection: observation over several days, accounting for external services, enabling it, testing login, cart, order and payment,
- setting password strength and optionally reCAPTCHA on selected forms,
- testing on the test environment and rolling out to production.
- Minimum estimated time:
- 2FA - from 1 h,
- session verification - from 0.5 h,
- security headers - from 2 h,
- CSRF form protection - Bootstrap 5 template - from 3 h, Bootstrap 4 template - from 4 h,
- password strength - from 1 h,
- reCAPTCHA - from 1 h,
- the whole package - Bootstrap 5 template - from 8 h, Bootstrap 4 template - from 10 h.
- The time for a specific implementation depends on its scope - we quote it individually.
- What the time depends on:
- the store template - custom templates require adjusting forms and scripts,
- the number of external services sending data to the store (payment gateways, couriers, ERP, marketplaces),
- third-party scripts and widgets on store pages - may require adjusting headers,
- the store version - a store older than 2.35 needs an update first (quoted separately),
- a content source policy tailored to the store's scripts - quoted separately.
- 2FA applies to the admin panel - store customers log in with a password (or via Google, if that module is enabled).
- 2FA settings (method, trusted browsers) are changed by each admin on their own account. After enabling 2FA in the store, check that every admin has configured it on their account.
- 2FA has no backup codes - we recommend that at least two admins have active 2FA, and that the authenticator app is set up on a company phone.
- 2FA does not cover access via a REST API or MCP key - such keys must be protected like passwords and removed once cooperation ends.
- Clearing browser cookies (or, when tied to the browser version, updating the browser) requires entering the code again.
- Session verification may log out users whose network changes during a visit (e.g. a phone switching between Wi-Fi and mobile data, some corporate networks and VPNs). It's worth testing this against the store's traffic before enabling it.
- CSRF form protection enabled without preparation can block notifications from payment gateways and integrations - which is why it requires implementation, not just switching it on.
- Security headers raise the level of protection but don't replace a policy tailored to a specific store's scripts.
- Banning embedding in frames on other sites also blocks intentional embedding of the store on other pages (e.g. a configurator on a partner's site) - such a case requires a settings change.
- Browser-enforced HTTPS only works for a store with an SSL certificate.
- The mechanisms don't replace the store's security policy - strong, unique admin passwords, removing former employees' accounts (from version 2.35.63, automatic closing of login for inactive accounts and the Disable login button help with this - see Admin permissions), and protecting staff mailboxes and computers.
- We do not review the configuration for legal compliance - GDPR requirements, the privacy policy and incident handling procedures are set by the store.
- Two-factor login for store customers, e.g. for B2B company accounts.
- Hardware security keys and passkeys for panel login.
- A content source policy tailored to a specific store's scripts, with separate settings for the test and production environments.
- An e-mail notification about a panel login from a new device.
- A security report in the panel - who has 2FA enabled, active API keys, and a consolidated overview of recent logins (today the last login date is visible on every admin account).
Does enabling security require code changes to the store?
Not in most cases. The mechanisms are part of the platform - enabling them is configuration and switching things on in the panel, usually a few hours rather than a project built from scratch.
Does two-factor login (2FA) also cover store customers?
No. 2FA applies to the admin panel. Store customers log in with a password (or via Google, if that module is enabled).
How long does enabling the full security package take?
From 8 h with the Bootstrap 5 template, or from 10 h with Bootstrap 4. Individual mechanisms can also be enabled separately, e.g. 2FA alone from 1 h.
Are REST API and MCP keys protected by two-factor login?
No. 2FA does not cover access via a REST API or MCP key - such keys must be protected like passwords and removed once cooperation ends.
Can CSRF protection block the store's integrations?
It can, if enabled without preparation. That's why we implement it with traffic observation and by accounting for external services (payments, couriers, ERP), rather than just switching it on.
Is the test-environment store visible in search engines?
No. The test store is only accessible to people with an access link - all other visits, including search engine crawlers, are redirected.
Want to check which safeguards are active in your store? Contact the Hummerce team (in Polish).
- Panel configuration: Configuration -> Settings:
- group Two-factor admin authorization - global 2FA switch, trusted browsers and their validity, browser version verification, lockout after failed codes,
- group Security - CSRF filter (store), CSRF filter (admin), Security headers,
- group Customers - Verify user sessions, Refresh session id after login and logout,
- group Administration - Verify admin sessions,
- group Passwords - password strength settings,
- group reCaptcha,
- group Test mode management - test store access and the redirect address.
- Admin account: Configuration -> Admins, section Two-factor authorization - method selection, authenticator app, revoking trusted browsers, unlocking the account.
- Roles and permissions: Configuration -> Roles (Admin permissions).
- History: Status -> History (Change history).
¶ REST API and MCP
Access via a key or API account, with the permissions of the panel account (REST API). MCP keys use the same permissions as the panel account and - like REST API access - are not covered by two-factor login (see Limitations).
Mail templates are changed in Email templates and alerts, store messages in the message editor.
| Alert |
Recipient |
When |
admin2FACodeEmailAlert (template admin2FACodeEmail) |
admin |
logging into the panel with the "code via e-mail" method |
The template is created automatically when the module is enabled, in the Polish and English versions. Variables in the template: $code - the verification code, $ttlMinutes - the code's validity in minutes, $userSymbol - the admin's login.
The message msg.passwordStrength.custom describes the requirements for a custom password strength rule (shown below the password field).