Infrastructure Security

Infrastructure Security

Technical security controls across hosting, network, database, and application layers.

Tatvam Cloud Solutions, LLP | March 2026

1. Architecture Overview

WiserReview is built on a microservices architecture where each service is independently deployed, scaled, and maintained within its own Docker container. Fault isolation ensures an issue in one service does not cascade to others.

Core Services

ServicePurposeHosting
Backend APIBusiness logic, authentication, integrationsAzure App Services
DashboardMerchant-facing web application (React SPA)Azure App Services
Review Display ServiceReview rendering, display logic, async job processing, event trackingAzure App Services
Widget Service (Pixel JS)Review widget rendering on merchant storefrontsCloudflare CDN
Image ProcessingMedia optimization, resizing, cloud storageAzure App Services

Production Domains

DomainServiceProtection
api.wiserreview.comBackend APICloudflare WAF + TLS
rs.wiserreview.comReview Display ServiceCloudflare WAF + TLS
embed.wiserreview.comWidget CDNCloudflare CDN + TLS

2. Network Security

PUBLICEDGEAPPLICATIONDATAZONE 1 — PUBLICInternet: Shoppers & MerchantsHTTPS requests via browserAll traffic filtered before reaching application serversHTTPS / TLS 1.2+ZONE 2 — CLOUDFLARE EDGEALL external traffic filtered hereWAFOWASP Top 10DDoSL3/L4/L7Bot Detection+ TurnstileTLS 1.2+TerminationCDN300+ locationsTLS 1.2+ZONE 3 — AZURE APP SERVICESContainer isolation · Auto-scaling · No SSH access · GitHub Actions deploys onlyBackend APIapi.wiserreview.comDockerReview Display Svcrs.wiserreview.comDockerDashboard & Other Servicesapp.wiserreview.comDockerIP Whitelist OnlyZONE 4 — DATA ZONENo public endpoints, private network onlyPrivateMongoDB AtlasIP WhitelistedAES-256 at restTLS connections onlyReplica sets with HARedis CachePassword Auth OnlyNo PII storedWorkspace-scoped keysTTL-based expirationAzure Blob / AWS S3Server-side AES-256Signed URLs onlyNo public bucket accessMedia files only

All traffic passes through Cloudflare before reaching Azure-hosted services. The data zone has no public endpoints.

2.1 Cloudflare Protection

All external traffic routes through Cloudflare before reaching Azure-hosted services:

  • Web Application Firewall (WAF): Managed rulesets protecting against OWASP Top 10, SQL injection, XSS, and other common attack vectors
  • DDoS Mitigation: Automatic L3/L4/L7 DDoS protection
  • Bot Management: Intelligent bot detection and challenge mechanisms
  • TLS Termination: TLS 1.2+ enforced on all endpoints; HTTP requests automatically redirected to HTTPS
  • Edge Caching: Static assets cached at 300+ global edge locations

2.2 Network Isolation

  • Database Access: MongoDB Atlas clusters are restricted via IP whitelisting; only Azure App Service IPs are allowed
  • Redis Cache: Password-authenticated connections; no public endpoint exposure
  • Azure Virtual Network: Services communicate over Azure's internal network
  • Container Isolation: Each microservice runs in its own Docker container with process-level and resource-level isolation

2.3 Rate Limiting

Endpoint CategoryLimitWindow
AI text generation endpoints20 requests10 minutes
Review submissionRate limitedPer IP
General APIStandard limitsPer IP

3. Authentication & Authorization

3.1 API Authentication

  • JWT tokens are required on every API request, signed with a server-side secret key
  • Token signing uses a server-side secret stored in environment variables
  • Tokens have defined expiration policies

3.2 Platform Integration

  • OAuth 2.0 authorization code flow for all supported e-commerce platform integrations
  • We only request the minimum API scopes required from each platform
  • Third-party platform passwords are never stored. We only keep OAuth access tokens

3.3 Platform Integration Security

  • Session tokens are verified against the app secret on every request
  • All incoming platform event notifications are validated via HMAC signature
  • Embedded app integrations use the platform's native session management

3.4 Password Security

  • Passwords are hashed with bcrypt
  • Passwords are never stored in plaintext or any reversible format
  • Sensitive data fields get an additional AES encryption layer before storage

3.5 Access Control (RBAC)

  • Three roles per workspace: Admin, Editor, and Viewer
  • Each workspace is logically isolated. Users can only access data within their own workspace
  • Cloudflare Turnstile protects registration and public forms from bot abuse

4. Data Encryption

4.1 Encryption in Transit

ConnectionProtocol
Browser ↔ Cloudflare TLS 1.2+ (HTTPS enforced)
Cloudflare ↔ Azure App Services TLS 1.2+
App Services ↔ MongoDB Atlas TLS encrypted connections
App Services ↔ Redis Encrypted connections with password auth
App Services ↔ Azure Service Bus TLS encrypted
Email delivery (AWS SES) TLS encrypted

4.2 Encryption at Rest

StorageEncryption Method
MongoDB Atlas AES-256
Azure Blob Storage Server-side encryption (AES-256)
AWS S3 Server-side encryption (AES-256)
Sensitive database fields Application-level AES encryption before storage

5. Database Security

5.1 MongoDB Atlas

  • •Replica sets with automatic failover
  • •Continuous backups with point-in-time recovery
  • •Access restricted via IP whitelisting
  • •All data encrypted at rest with AES-256
  • •All app-to-database connections are TLS encrypted

5.2 Redis Cache

  • •All connections require password authentication
  • •Used exclusively for transient caching, no PII stored
  • •Cache keys are scoped per workspace
  • •Cached data has TTL-based automatic expiration

5.3 File Storage

  • •Azure Blob Storage and AWS S3. All media stored with server-side encryption
  • •File access is via time-limited signed URLs
  • •No public bucket access
  • •Uploaded images are resized and optimized before storage

6. Application Security

6.1 Input Validation

  • ObjectID validation using regex patterns for MongoDB document references
  • Content-type validation on incoming webhook payloads
  • File type validation on uploads (MIME type checking)

6.2 Security Headers

  • Helmet.js security headers in production environments
  • Content Security Policy (CSP) headers on embedded app integrations
  • Cloudflare adds additional security headers at the edge

6.3 Dependency Management

  • Docker multi-stage builds minimize attack surface by excluding dev dependencies
  • Package dependencies pinned to specific versions

7. CI/CD & Deployment Security

DeveloperGit push to feature branchGitHub Pull RequestCode review · Security checklist · Engineering Lead approvalReview requiredGitHub ActionsCI/CD triggered on merge to mainEncrypted secrets vault — no credentials in logsDocker BuildMulti-stage build · No dev deps · No source maps · No build toolsMinimal attack surfaceAzure Container RegistryAuthenticated access only · No public pulls · Version historyPrivate registryStaging DeployHealth checks · Smoke tests · Sentry baseline verificationVerified before productionProduction DeployAzure App Services · Auto-scaling · No SSH access · Health monitoredPost-Deploy MonitoringHealth endpoints · Sentry error rates · Latency monitoringAll systems greenInstant rollback — previous image

All deployments go through GitHub Actions. Credentials are stored in encrypted secrets — never in source code.

  • GitHub Actions: Automated deployment pipeline with no manual access to production servers
  • Encrypted Secrets: All credentials and API keys stored in GitHub's encrypted secrets vault; never in source code or build logs
  • Container Registry: Docker images stored in Azure Container Registry with authenticated access only
  • Docker Multi-Stage Builds: Production images contain only runtime dependencies; no build tools, source maps, or development packages
  • No SSH Access: Production servers are managed via Azure App Services; no direct SSH access to containers

8. Monitoring & Incident Response

8.1 Monitoring

CapabilityImplementation
Error TrackingReal-time error monitoring and alerting via Sentry
Application LoggingAll API requests logged with response time monitoring; abnormal latency (>5s) triggers alerts
Error Audit TrailAll errors captured with timestamps, context, and stack traces in dedicated log collections
Real-Time AlertsCritical production errors trigger immediate Slack notifications
Health ChecksDedicated health-check endpoints monitor database and cache connectivity
Event Tracking16+ event types tracked for usage analytics and anomaly detection

8.2 Incident Response Process

  1. 1Detection: Automated monitoring detects anomalies (Sentry, health checks, latency alerts)
  2. 2Triage: Real-time Slack notifications alert the engineering team; severity assessed
  3. 3Containment: Affected service isolated if necessary; traffic can be rerouted via Cloudflare
  4. 4Resolution: Root cause identified and fix deployed via CI/CD pipeline
  5. 5Post-Mortem: Root cause analysis documented; preventive measures implemented
  6. 6Notification: Affected customers notified as appropriate (within 72 hours for data breaches per GDPR)

9. Availability & Disaster Recovery

AspectDetails
Hosting SLAAzure App Services: 99.95% uptime SLA
Auto-ScalingAutomatic horizontal scaling under high load (e.g., Black Friday, large campaign sends)
Database HAMongoDB Atlas replica sets with automatic failover
Global CDNCloudflare CDN with 300+ edge locations for low-latency widget delivery
Queue ResilienceAzure Service Bus with automatic retry and dead-letter handling. No messages are lost
Disaster RecoveryAutomated database backups with point-in-time recovery; multi-region capable infrastructure

Contact

For infrastructure security inquiries:

Tatvam Cloud Solutions, LLP

[email protected]