Layered security, built into daily ops !

Shopnix Security Stack

We know you trust us with your store, your customer details, and your order data. So we treat security as our daily work, not a one-time checklist. We have built Shopnix with multiple layers of security called the Shopnix Security Stack. The intention is that each layer brings in a level of protection and ensures your data is ringfenced. Below is the design of the security stack and the mechanisms protecting your data at various stages.

Explore our Stack

UFW Firewall

We run UFW with a deny-by-default rule on every production machine.
Only required inbound routes are opened. Everything else stays blocked.

Port Restriction

We keep our admin tools and database ports off the public internet.
SSH runs on a non-standard port, with source restrictions, which helps us reduce random scans on your store.

Fail2Ban

Fail2Ban watches auth logs and blocks repeat offenders automatically.
If one IP keeps failing login checks, we ban it before it turns noisy.

Deny by Default

When a new service is added, it stays closed first.
We open only what that service needs after review.

Internal Segmentation

We separate public web routes from internal service routes.
Database and background workers are kept on private paths.

DDoS Readiness

Traffic spikes are tracked 24x7 at edge and server level.
Rate limits are applied in minutes when abuse patterns appear.

SSH Hardening

We disable SSH root login.
Access is key-based only, and keys are rotated when team access changes.

Least Access

Only a limited operations group can access production shell.
Every login maps to a named user account. No shared credentials.

Security Updates

Critical security patches are applied within 48 hours of verified CVE impact.
Regular OS and package updates run in planned maintenance windows.

AllowUsers Policy

We use SSHD AllowUsers rules to whitelist exact system users.
Unknown local accounts cannot connect to production over SSH.

Auth Attempt Limits

We cap retries with MaxAuthTries and short auth timeouts.
Brute-force attempts are rate-limited and then blocked.

Host Logging

We retain our auth and service logs for incident tracing.
When something looks wrong, we can quickly see who logged in and from where, and what was changed.

Apache Hardening

We harden Apache2 vhost rules and remove modules we do not need.
Server signature details are hidden to reduce fingerprinting.

MySQL Controls

Application users get scoped MySQL permissions. They do not run as full admins.
Remote MySQL access is kept closed by default.

Patch Cycle

Apache2, MySQL, PHP, and OS packages follow a monthly patch cycle.
For high-risk CVEs, we fast-track fixes inside 48 hours after impact review.

Directory Exposure

We disable directory listing using Options -Indexes on public routes.
Your file layout stays hidden from casual scans. Not perfect, but useful layer.

DB Scope Control

Read/write traffic and maintenance tasks use different database users.
That way, one leaked credential does less damage.

Startup Hygiene

We boot only required services.
Unused daemons stay disabled, which keeps the attack surface lean.

Input Validation

We validate request type, length, and format before any write operation.
If a field is malformed, we reject it early and log the event.

Secure Sessions

We trust server-side session state, not browser-side claims.
For privileged actions, session identity is checked again at execution time.

Safe File Handling

Uploads go through MIME checks, size checks, and safe rename rules.
Example: executable-looking uploads are blocked before storage.

Input Cleaning

We normalize incoming fields and apply output encoding where required.
This helps block common script injection paths.

Type Enforcement

Order totals, IDs, and dates are type-checked strictly.
Bad values fail fast instead of leaking into business logic.

Request Throttling

We throttle login, OTP, and reset routes with per-IP and per-session limits.
When you take orders at 2 AM, our checks are still active and watching.

Dual Validation

Frontend validation keeps forms easy to use.
Backend validation is the final gate, always.

Prepared Queries

We use prepared statements for database writes and reads.
User input is bound as data, not executed as SQL.

Session Identity Checks

Before account updates, we verify session identity and ownership.
This protects coupon use, profile edits, and order-linked actions.

OTP Controls

OTP resends have cooldown windows and retry limits.
Codes expire quickly and must match both user flow and session context.

reCAPTCHA

We apply reCAPTCHA on high-abuse routes.
That includes public forms where bot traffic is common.

Workflow Validation

Checkout follows strict state checks. No step skipping.
If required context is missing, we stop and ask for correction.

Social Token Verification

We verify social login tokens with provider checks before sign-in.
Only verified identity fields are linked to customer accounts.

Tenant Boundaries

We enforce tenant-level checks on every account-scoped request.
One store cannot read or modify another store's data.

HTTPS/TLS

Admin and storefront sessions run over HTTPS only.
Login credentials and cookies are transmitted through TLS.

Platform Encryption

We enforce encryption in transit across our platform endpoints.
Your customer card data is processed by payment gateways and is not stored as raw card numbers on our servers, this is important for your trust.

Audit Signals

We log login events, role changes, and critical actions.
These logs help us investigate quickly when something feels off.

Session-Scoped Reads

Sensitive data reads require active session identity.
Expired or invalid sessions are blocked immediately.

Prepared Data Access

We use prepared data access paths in PHP service layers.
This keeps injection risk low across store operations.

Retention Controls

We keep logs and backups on defined retention windows, not forever.
That gives enough history for restore and forensic review without over-retaining data.

Role Model

We use role-based access for owner, admin, operator, and limited users.
People get only what they need to run your store, and ours team can audit this when needed.

Privilege Review

Access rights are reviewed on a monthly cycle.
Unused permissions are removed so old access does not linger.

Production Restriction

Production shell access is restricted to a small named operations set.
Risky actions are logged and traceable.

Role Separation

Billing, order management, and settings controls are separated by role.
This reduces the blast radius if one account is compromised.

Privilege Revocation

When team roles change, we revoke stale access promptly.
Temporary elevated access is time-bound by policy.

Session Identity Binding

Critical actions are bound to active session identity.
If identity checks fail, the action is stopped before any write.

Session Management

Sessions expire automatically and require re-auth for sensitive tasks.
Password reset and account-change flows use tighter session checks.

Log Monitoring

We review Apache, PHP, auth, and app logs every day.
Suspicious patterns are triaged as part of routine operations.

Alerting

High-signal events trigger operations alerts immediately.
Repeated auth failures, abnormal spikes, and service anomalies are escalated.

Uptime Checks

Storefront and admin URLs are checked 24x7.
If something drops, we start investigation first and communication next. Sometimes alerts comes noisy but we handle it.

Abuse Tracking

We track bot traffic, credential stuffing patterns, and request floods.
Source patterns are blocked at firewall and application level.

Operational Logs

Operational logs are retained for troubleshooting and evidence.
This helps us answer the practical question fast: what changed and when.

Performance Watch

Latency, error rate, CPU, and memory trends are continuously tracked.
We prefer early fixes over outage firefighting.

Scheduled Backups

We run backups on fixed schedules: daily for live order data and weekly for full-store snapshots.
Jobs are automated and monitored.

Restore Testing

We run restore drills every month.
If a backup cannot restore cleanly, we do not count it as valid.

Recovery Runbook

Recovery steps are documented in an internal runbook with clear ownership.
During incidents, this removes guesswork and reduces recovery time.

Multi-Copy Strategy

We keep 3 backup copies: production snapshot, offsite copy, and a cold backup archive.
If one path fails, we fall back to another copy. So your restore chances are better.

Integrity Checks

Backup files are checked for readability and completeness.
Corrupt sets are flagged and rebuilt quickly.

Priority Restore Order

Login, catalog, checkout, and orders come back first.
Secondary workloads restore after core commerce flow is stable.

SECURITY

We got you !

Security at Shopnix is real for us.

Along with DigitalOcean’s highly secure servers and our security stack, we keep your store secure across the network, infrastructure, app, database and APIs layers.

However, no system is 100% unbreakable. What we can promise is this - we take this seriously, and we constantly monitor for issues, breaking attempts, attacks and we respond fast when we see something. We also have a solid backup and recovery system in place, so if something bad happens, we can restore your store to a recent state with minimal data loss

Shopnix Security — Your E-Commerce Partner

Ready to Build Your Online Store?

Join growing businesses that are scaling faster while spending less on platform costs