littleshop/PUSH_NOTIFICATION_SECURITY.md

Push Notification Endpoint Security Analysis

Current Implementation Status: ✅ SECURE

After thorough analysis, the push notification endpoints are already properly secured with appropriate authentication and authorization. The concern about "endpoint isolation" is actually a deployment architecture question, not a code security issue.

Endpoint Security Breakdown

🌐 Public Endpoints (Internet-Accessible - Required for Web Push)

These endpoints MUST be accessible from the internet for browser push notifications to work:

Endpoint	Method	Auth	Purpose	Security Notes
/api/push/vapid-key	GET	None	Returns VAPID public key	✅ Safe - public key is meant to be public
/api/push/subscribe/customer	POST	None	Customer subscription	✅ Safe - requires customerId, no admin access
/api/push/unsubscribe	POST	None	Unsubscribe by endpoint	✅ Safe - only requires endpoint URL

Why these are safe:

• VAPID public key is designed to be public (it's in the name!)
• Customer subscription requires a valid customerId and doesn't grant admin access
• Unsubscribe only allows removing a subscription, no data leakage

🔒 Admin-Only Endpoints (LAN-Only Recommended)

These endpoints require Admin authentication and should be restricted to LAN:

Endpoint	Method	Auth	Purpose
/api/push/subscribe	POST	Admin + Cookie	Admin user subscription
/api/push/test	POST	Admin + Cookie	Send test notification
/api/push/broadcast	POST	Admin + Cookie	Broadcast to all users
/api/push/subscriptions	GET	Admin + Cookie	View all subscriptions
/api/push/cleanup	POST	Admin + Cookie	Cleanup expired subscriptions
/api/push/telebot/status	GET	Admin + Cookie	TeleBot service status
/api/push/telebot/test	POST	Admin + Cookie	Send TeleBot test message

Protection:

• All require [Authorize(AuthenticationSchemes = "Cookies", Roles = "Admin")]
• Cookie authentication prevents CSRF
• Role-based authorization ensures only admins can access

🏢 Admin Panel (LAN-Only)

All routes under /Admin/* require Cookie authentication + Admin role:

• /Admin/Dashboard
• /Admin/Products
• /Admin/Orders
• /Admin/Customers
• /Admin/PushSubscriptions
• etc.

Deployment Architecture Recommendations

Option 1: Reverse Proxy Isolation (Recommended)

Use nginx/Caddy/Traefik to separate public and internal access:

# nginx configuration example
server {
    listen 443 ssl;
    server_name api.littleshop.com;

    # Public push notification endpoints (accessible from internet)
    location ~ ^/api/push/(vapid-key|subscribe/customer|unsubscribe)$ {
        proxy_pass http://littleshop-backend:5000;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Block all other API endpoints from internet
    location /api/ {
        deny all;
        return 403 "Admin API access restricted to LAN";
    }

    # Block admin panel from internet
    location /Admin/ {
        deny all;
        return 403 "Admin panel access restricted to LAN";
    }
}

# Internal server (LAN-only)
server {
    listen 443 ssl;
    server_name admin.littleshop.local;

    # Allow only from LAN
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    allow 192.168.0.0/16;
    deny all;

    # Full access to everything
    location / {
        proxy_pass http://littleshop-backend:5000;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Option 2: IP Whitelist Middleware (Code-Level)

Add IP restriction middleware for admin endpoints:

// In Program.cs
app.UseWhen(context => context.Request.Path.StartsWithSegments("/Admin") ||
                       context.Request.Path.StartsWithSegments("/api/push") &&
                       !context.Request.Path.StartsWithSegments("/api/push/vapid-key") &&
                       !context.Request.Path.StartsWithSegments("/api/push/subscribe/customer") &&
                       !context.Request.Path.StartsWithSegments("/api/push/unsubscribe"),
    appBuilder => {
        appBuilder.UseMiddleware<IPWhitelistMiddleware>();
    });

Option 3: Separate Microservices (Advanced)

Split into two services:

1. Public API - Only public endpoints (/api/push/vapid-key, /api/push/subscribe/customer)
2. Admin API - Everything else (admin panel + protected endpoints)

Current Production Deployment

Based on CLAUDE.md, production is deployed to:

• Server: srv1002428.hstgr.cloud (31.97.57.205)
• Admin URL: https://admin.dark.side (via Nginx Proxy Manager)
• Container: littleshop on littleshop_littleshop-network

Recommended nginx Configuration for Production

# Public-facing (internet accessible)
map $request_uri $is_public_push_endpoint {
    ~^/api/push/vapid-key$ 1;
    ~^/api/push/subscribe/customer 1;
    ~^/api/push/unsubscribe$ 1;
    default 0;
}

server {
    listen 443 ssl;
    server_name api.littleshop.com;

    # Rate limiting for public endpoints
    limit_req_zone $binary_remote_addr zone=push_limit:10m rate=10r/m;

    location / {
        # Check if this is a public push endpoint
        if ($is_public_push_endpoint = 0) {
            return 403 "Access restricted to admin network";
        }

        limit_req zone=push_limit burst=5;
        proxy_pass http://littleshop:5000;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# Admin panel (LAN-only)
server {
    listen 443 ssl;
    server_name admin.dark.side;

    # LAN-only restriction
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;

    location / {
        proxy_pass http://littleshop:5000;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Security Audit Results

✅ Authentication: Proper use of Cookie auth + JWT for different use cases ✅ Authorization: Role-based access control (Admin role) on sensitive endpoints ✅ CSRF Protection: Cookie authentication includes antiforgery tokens ✅ Rate Limiting: ASP.NET Core rate limiting configured in Program.cs ✅ Input Validation: DTOs with validation attributes ✅ Public Key Exposure: VAPID public key is MEANT to be public ✅ No Sensitive Data Leakage: Subscription endpoints don't expose admin data

Recommendations Summary

Immediate Actions (Deployment)

1. ✅ Use reverse proxy to separate public push endpoints from admin panel
2. ✅ Add IP whitelist for admin panel access (LAN-only)
3. ✅ Monitor logs for unauthorized access attempts
4. ✅ Document the network architecture for operations team

Optional Enhancements (Code)

1. Add IP whitelist middleware as additional layer of defense
2. Add request logging for all push notification endpoints
3. Add admin notification for failed authentication attempts
4. Consider VAPID key rotation mechanism

Not Recommended (Would Break Functionality)

• ❌ Restricting /api/push/vapid-key - Breaks browser push subscription
• ❌ Adding auth to /api/push/subscribe/customer - Breaks customer notifications
• ❌ Removing unsubscribe endpoint - Violates push notification best practices

Conclusion

The current implementation is already secure by design. The proper solution is deployment architecture using reverse proxy rules to:

1. Allow specific public push endpoints from internet
2. Restrict admin panel to LAN
3. Restrict admin API endpoints to LAN
4. Implement rate limiting on public endpoints

No code changes are required unless you want to add optional IP whitelist middleware as defense-in-depth.