[SEC] Dynamic CORS + CSP + Merchant Origin Allowlisting

[oomokaro1]

[SEC] Dynamic CORS + CSP + Merchant Origin Allowlisting

Priority: High

Difficulty: Hard
Estimated Effort: 2-3 days
Relevant Packages: OrbitStream_backend/, orbitstream_docs/
Labels: security, enhancement, priority:high

Requirements

1. Dynamic Origin Allowlisting

• Add a cors_origins JSONB column to the merchants table
• Each merchant can configure allowed origins via PATCH /merchants/me/cors
• The CORS middleware reads from a Redis-backed cache (refreshed every 5 minutes)
• If the merchant has no configured origins, only the platform domain is allowed

2. Route-Based CORS Policies

• Public routes (GET /v1/checkout/sessions/:id, POST /merchants/register): Allow all origins
• Merchant API routes (/v1/checkout/*, /v1/webhooks/*): Allow only the merchant's configured origins + platform domain
• Dashboard routes (/merchants/*, /auth/*): Allow only the platform domain

3. CORS Middleware

Implement a DynamicCorsMiddleware that:

• Reads the Origin header
• Checks against the allowed list for the route group
• Sets correct headers: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers
• Handles preflight OPTIONS with Access-Control-Max-Age: 86400
• Returns 403 for disallowed origins (not just missing headers)

4. Security Headers

Add these headers to all responses:

• Strict-Transport-Security: max-age=31536000; includeSubDomains
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• X-XSS-Protection: 1; mode=block
• Referrer-Policy: strict-origin-when-cross-origin
• Content-Security-Policy: default-src 'self' (adjust for checkout page)

5. API Endpoints

• GET /merchants/me/cors — list configured origins (JWT auth)
• PUT /merchants/me/cors — set allowed origins (JWT auth)
• Body: { "origins": ["https://myshop.com", "https://staging.myshop.com"] }

6. Testing

• Unit test: valid origin matches, invalid origin rejected
• Unit test: preflight OPTIONS handled correctly
• Unit test: public routes allow all origins
• Unit test: merchant routes only allow configured origins
• Unit test: security headers present on all responses
• Integration test: request from unknown origin gets 403
• Integration test: request from allowed origin succeeds

[CAESARIAN-ATHENS]

---

Application: [SEC] Dynamic CORS + CSP + Merchant Origin Allowlisting

Summary

I would like to work on this security enhancement for OrbitStream. The issue touches several critical areas—dynamic CORS enforcement, merchant-specific origin allowlisting, Redis caching, route-level policies, CSP and security headers, and comprehensive testing.

My approach focuses on providing a secure-by-default implementation while minimizing performance overhead through cache-backed origin resolution.

---

Understanding of the Problem

Current CORS behavior appears to be static and insufficient for multi-tenant merchant environments.

This introduces risks such as:

• Unauthorized browser access from malicious domains.
• Cross-origin abuse.
• Missing CSP protections.
• Lack of explicit rejection for disallowed origins.
• Weak separation between public, merchant, and dashboard APIs.

The objective is to establish:

1. Merchant-specific origin allowlists.
2. Route-group-aware CORS policies.
3. Redis-backed caching.
4. Strong browser security headers.
5. Explicit 403 responses for invalid origins.
6. Complete unit and integration coverage.

---

Implementation Plan

---

Phase 1: Database Layer

Migration

Add:

ALTER TABLE merchants
ADD COLUMN cors_origins JSONB NOT NULL DEFAULT '[]';

Example:

[
  "https://myshop.com",
  "https://staging.myshop.com"
]

Properties:

• Array of HTTPS origins.
• Empty array means fallback to platform domain only.
• JSONB indexing can be added later if necessary.

---

Phase 2: Merchant API

GET /merchants/me/cors

JWT protected.

Response:

{
  "origins": [
    "https://myshop.com",
    "https://staging.myshop.com"
  ]
}

---

PUT /merchants/me/cors

JWT protected.

Request:

{
  "origins": [
    "https://myshop.com",
    "https://staging.myshop.com"
  ]
}

Validation:

• Must be valid URLs.
• HTTPS only.
• No wildcards.
• Remove duplicates.
• Normalize origin values.

Example normalization:

https://myshop.com/

becomes

https://myshop.com

After update:

• Persist to database.
• Refresh Redis cache immediately.

---

Phase 3: Redis-backed Origin Cache

Cache key:

merchant:cors:{merchant_id}

Example value:

[
  "https://myshop.com",
  "https://staging.myshop.com"
]

TTL:

300 seconds

(5 minutes)

Flow:

Request
    ↓
Middleware
    ↓
Redis
    ↓ cache miss
Database
    ↓
Update Redis
    ↓
Validate Origin

Benefits:

• Avoid database lookup on every request.
• Scales with large merchant counts.
• Supports immediate refresh after PUT.

---

Phase 4: Route-based CORS Policies

Public Routes

Examples:

GET /v1/checkout/sessions/:id
POST /merchants/register

Policy:

Access-Control-Allow-Origin: *

These routes intentionally remain public.

---

Merchant APIs

Examples:

/v1/checkout/*
/v1/webhooks/*

Allowed origins:

merchant origins
+
platform domain

Any unknown origin:

403 Forbidden

rather than silently omitting CORS headers.

---

Dashboard APIs

Examples:

/merchants/*
/auth/*

Allowed origin:

https://orbitstream.com

Only the platform frontend should access these endpoints.

---

Phase 5: DynamicCorsMiddleware

Responsibilities:

---

Read Origin Header

let origin = req.headers().get("Origin");

---

Determine Route Group

Public
Merchant
Dashboard

---

Resolve Allowed Origins

Merchant routes:

Vec<String>

obtained from:

Redis → DB fallback

---

Validate Origin

allowed_origins.contains(origin)

---

Set Headers

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Credentials
Vary: Origin

Methods:

GET
POST
PUT
PATCH
DELETE
OPTIONS

Headers:

Authorization
Content-Type
X-Requested-With

---

OPTIONS Handling

Return:

204 No Content

Headers:

Access-Control-Max-Age: 86400

(24-hour browser cache)

---

Explicit Rejection

Instead of:

No CORS headers

return:

HTTP/1.1 403 Forbidden

Response:

{
  "error": "Origin not allowed"
}

This prevents ambiguity and improves observability.

---

Phase 6: Security Headers Middleware

Applied globally.

HSTS

Strict-Transport-Security:
max-age=31536000; includeSubDomains

---

MIME sniffing prevention

X-Content-Type-Options:
nosniff

---

Frame protection

X-Frame-Options:
DENY

---

XSS protection

X-XSS-Protection:
1; mode=block

---

Referrer policy

Referrer-Policy:
strict-origin-when-cross-origin

---

CSP

Default:

Content-Security-Policy:
default-src 'self'

Checkout pages can be expanded as necessary:

script-src 'self';
style-src 'self';
img-src 'self' data:;
connect-src 'self';
frame-ancestors 'none';
base-uri 'self';
object-src 'none';

---

Testing Strategy

Unit Tests

Valid origin accepted

assert_eq!(status, 200);

---

Invalid origin rejected

assert_eq!(status, 403);

---

OPTIONS preflight

Verify:

204 response
Access-Control-Max-Age = 86400

---

Public route

Should allow:

*

---

Merchant route

Only configured origins accepted.

---

Security headers

Verify presence of:

• HSTS
• CSP
• X-Frame-Options
• Referrer-Policy
• X-Content-Type-Options

---

Integration Tests

Unknown Origin

Request:

Origin: https://evil.com

Expected:

403 Forbidden

---

Allowed Merchant

Request:

Origin: https://myshop.com

Expected:

200 OK

and:

Access-Control-Allow-Origin:
https://myshop.com

---

Cache Miss

Verify:

DB → Redis

---

Cache Hit

Verify:

Redis only

---

Additional Security Improvements

While implementing this issue, I would also ensure:

Origin normalization

Prevent bypasses such as:

https://myshop.com/
https://myshop.com:443
HTTPS://MYSHOP.COM

by canonicalizing origins before storage and comparison.

---

Wildcard rejection

Disallow:

*
*.myshop.com

to avoid accidental overexposure.

---

Vary Header

Include:

Vary: Origin

to prevent cache poisoning.

---

Credentials support

Ensure:

Access-Control-Allow-Credentials

never appears with:

Access-Control-Allow-Origin: *

to remain RFC-compliant.

---

Deliverables

• Database migration for cors_origins.
• Merchant CORS management endpoints.
• Redis-backed origin cache.
• Dynamic route-aware middleware.
• Global security headers middleware.
• CSP support.
• Comprehensive unit tests.
• Integration tests.
• Documentation updates under orbitstream_docs/.

---

Estimated completion

2–3 days

with emphasis on correctness, defense-in-depth, and full test coverage to ensure OrbitStream's multi-tenant API surface remains secure and scalable.

[oomokaro1]

Application: [SEC] Dynamic CORS + CSP + Merchant Origin Allowlisting

Summary

I would like to work on this security enhancement for OrbitStream. The issue touches several critical areas—dynamic CORS enforcement, merchant-specific origin allowlisting, Redis caching, route-level policies, CSP and security headers, and comprehensive testing.

My approach focuses on providing a secure-by-default implementation while minimizing performance overhead through cache-backed origin resolution.

Understanding of the Problem

Current CORS behavior appears to be static and insufficient for multi-tenant merchant environments.

This introduces risks such as:

• Unauthorized browser access from malicious domains.
• Cross-origin abuse.
• Missing CSP protections.
• Lack of explicit rejection for disallowed origins.
• Weak separation between public, merchant, and dashboard APIs.

The objective is to establish:

1. Merchant-specific origin allowlists.
2. Route-group-aware CORS policies.
3. Redis-backed caching.
4. Strong browser security headers.
5. Explicit 403 responses for invalid origins.
6. Complete unit and integration coverage.

Implementation Plan

Phase 1: Database Layer

Migration

Add:

ALTER TABLE merchants
ADD COLUMN cors_origins JSONB NOT NULL DEFAULT '[]';
Example:

[
"https://myshop.com",
"https://staging.myshop.com"
]
Properties:

• Array of HTTPS origins.
• Empty array means fallback to platform domain only.
• JSONB indexing can be added later if necessary.

Phase 2: Merchant API

GET /merchants/me/cors

JWT protected.

Response:

{
"origins": [
"https://myshop.com",
"https://staging.myshop.com"
]
}

PUT /merchants/me/cors

JWT protected.

Request:

{
"origins": [
"https://myshop.com",
"https://staging.myshop.com"
]
}
Validation:

• Must be valid URLs.
• HTTPS only.
• No wildcards.
• Remove duplicates.
• Normalize origin values.

Example normalization:

https://myshop.com/
becomes

https://myshop.com
After update:

• Persist to database.
• Refresh Redis cache immediately.

Phase 3: Redis-backed Origin Cache

Cache key:

merchant:cors:{merchant_id}

Example value:

[
"https://myshop.com",
"https://staging.myshop.com"
]
TTL:

300 seconds

(5 minutes)

Flow:

Request
    ↓
Middleware
    ↓
Redis
    ↓ cache miss
Database
    ↓
Update Redis
    ↓
Validate Origin

Benefits:

• Avoid database lookup on every request.
• Scales with large merchant counts.
• Supports immediate refresh after PUT.

Phase 4: Route-based CORS Policies

Public Routes

Examples:

GET /v1/checkout/sessions/:id
POST /merchants/register

Policy:

Access-Control-Allow-Origin: *
These routes intentionally remain public.

Merchant APIs

Examples:

/v1/checkout/*
/v1/webhooks/*

Allowed origins:

merchant origins
+
platform domain

Any unknown origin:

403 Forbidden

rather than silently omitting CORS headers.

Dashboard APIs

Examples:

/merchants/*
/auth/*

Allowed origin:

https://orbitstream.com

Only the platform frontend should access these endpoints.

Phase 5: DynamicCorsMiddleware

Responsibilities:

Read Origin Header

let origin = req.headers().get("Origin");

Determine Route Group

Public
Merchant
Dashboard

Resolve Allowed Origins

Merchant routes:

Vec
obtained from:

Redis → DB fallback

Validate Origin

allowed_origins.contains(origin)

Set Headers

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Credentials
Vary: Origin

Methods:

GET
POST
PUT
PATCH
DELETE
OPTIONS

Headers:

Authorization
Content-Type
X-Requested-With

OPTIONS Handling

Return:

204 No Content

Headers:

Access-Control-Max-Age: 86400

(24-hour browser cache)

Explicit Rejection

Instead of:

No CORS headers

return:

HTTP/1.1 403 Forbidden
Response:

{
"error": "Origin not allowed"
}
This prevents ambiguity and improves observability.

Phase 6: Security Headers Middleware

Applied globally.

HSTS

Strict-Transport-Security:
max-age=31536000; includeSubDomains

MIME sniffing prevention

X-Content-Type-Options:
nosniff

Frame protection

X-Frame-Options:
DENY

XSS protection

X-XSS-Protection:
1; mode=block

Referrer policy

Referrer-Policy:
strict-origin-when-cross-origin

CSP

Default:

Content-Security-Policy:
default-src 'self'

Checkout pages can be expanded as necessary:

script-src 'self';
style-src 'self';
img-src 'self' data:;
connect-src 'self';
frame-ancestors 'none';
base-uri 'self';
object-src 'none';

Testing Strategy

Unit Tests

Valid origin accepted

assert_eq!(status, 200);

Invalid origin rejected

assert_eq!(status, 403);

OPTIONS preflight

Verify:

204 response
Access-Control-Max-Age = 86400

Public route

Should allow:

*

Merchant route

Only configured origins accepted.

Security headers

Verify presence of:

• HSTS
• CSP
• X-Frame-Options
• Referrer-Policy
• X-Content-Type-Options

Integration Tests

Unknown Origin

Request:

Origin: https://evil.com
Expected:

403 Forbidden

Allowed Merchant

Request:

Origin: https://myshop.com
Expected:

200 OK
and:

Access-Control-Allow-Origin:
https://myshop.com

Cache Miss

Verify:

DB → Redis

Cache Hit

Verify:

Redis only

Additional Security Improvements

While implementing this issue, I would also ensure:

Origin normalization

Prevent bypasses such as:

https://myshop.com/
https://myshop.com:443
HTTPS://MYSHOP.COM

by canonicalizing origins before storage and comparison.

Wildcard rejection

Disallow:

*
*.myshop.com

to avoid accidental overexposure.

Vary Header

Include:

Vary: Origin

to prevent cache poisoning.

Credentials support

Ensure:

Access-Control-Allow-Credentials

never appears with:

Access-Control-Allow-Origin: *

to remain RFC-compliant.

Deliverables

• Database migration for cors_origins.
• Merchant CORS management endpoints.
• Redis-backed origin cache.
• Dynamic route-aware middleware.
• Global security headers middleware.
• CSP support.
• Comprehensive unit tests.
• Integration tests.
• Documentation updates under orbitstream_docs/.

Estimated completion

2–3 days

with emphasis on correctness, defense-in-depth, and full test coverage to ensure OrbitStream's multi-tenant API surface remains secure and scalable.

I love your well structured and detailed approach.

I will assign you this issue.

[grantfox-oss]

🦊 GrantFox — @Chidubemkingsley has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #15)
2. Your PR will be reviewed by the OrbitStream maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@Chidubemkingsley's PR #22 was approved and merged by @oomokaro1.

🏆 @Chidubemkingsley: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (153 total points). Track your full progress on GrantFox.

👏 Great work, @Chidubemkingsley! Keep contributing to OrbitStream.