CORS Configuration for Public API #11512

flvndvd · 2025-03-20T20:50:26Z

This PR implements proper CORS handling for our public API endpoints (/v1/*) while maintaining existing development environment CORS support.

Context

CORS (Cross-Origin Resource Sharing) is a security feature implemented by browsers that prevents web pages from making requests to a different domain than the one that served the web page. Until now, our public API (/v1/*) has been primarily used by:

Backend services (where CORS doesn't apply)
Browser extensions via service workers (which are exempt from CORS restrictions)

However, as we're building a new Front extension to have Dust directly in the web application, we've discovered that our API wasn't properly handling CORS. This prevented the extension from making requests directly from browser-based JavaScript code.

Problem

When a web page from front-ext.dust.tt tries to make a request to dust.tt/v1/..., browsers block the request unless the server explicitly allows it through CORS headers. This is a security measure to prevent malicious websites from making unauthorized requests to our API on behalf of authenticated users.

Without proper CORS headers:

Requests from our frontend extension were being blocked by browsers
The browser's preflight (OPTIONS) requests were failing
Authenticated requests (with credentials) weren't possible

Solution

This PR implements proper CORS handling by:

Creating a centralized CORS configuration
Adding necessary CORS headers for both preflight and actual requests
Implementing strict origin validation for security
Maintaining existing development environment setup

Changes

CORS Configuration

Created a new config/cors.ts file to centralize CORS configuration
Implemented type-safe origin validation using TypeScript's type system
Limited allowed origins to only front-ext.dust.tt for production
Maintained development environment CORS settings for localhost:3010

Middleware Updates

Added specific CORS handling for /v1 routes
Separated CORS header logic into dedicated functions:
- setCorsHeaders() for public API endpoints with origin validation
- setDevCorsHeaders() for development environment
Clear separation between preflight and actual requests
Explicit error handling with 403 responses for:
- Missing origin header
- Unauthorized origins
- Unauthorized headers in preflight requests
Type-safe response handling

Technical Details

The CORS implementation follows security best practices:

No wildcard (*) origins allowed
Origin validation using TypeScript type checking
Credentials only enabled for validated origins
Explicit allowed methods and headers
Proper handling of preflight requests

Tests

Risk

Deploy Plan

tdraier · 2025-03-20T20:55:30Z

front/config/cors.ts

+  return ALLOWED_ORIGINS.includes(origin as AllowedOriginType);
+}
+
+export const DEV_ORIGIN = "http://localhost:3010" as const;


Is this the front plugin url in dev ? In development it may be nice to accept any origin starting with http://localhost (any port)

Yep, happy to change for a startsWith then.

tdraier · 2025-03-20T21:01:04Z

front/middleware.ts

+  if (isDevelopment() && origin === DEV_ORIGIN) {
+    response.headers.set("Access-Control-Allow-Origin", DEV_ORIGIN);
+    response.headers.set("Access-Control-Allow-Credentials", "true");
+  } else if (origin && isAllowedOrigin(origin)) {


both branches are similar, we can use a single test ( second one with the requested origin )

tdraier · 2025-03-20T21:05:14Z

front/middleware.ts

+    "Access-Control-Allow-Headers",
+    "Authorization, Content-Type, X-Request-Origin, x-Commit-Hash, X-Dust-Extension-Version"
+  );
+}


at some point the middleware should return a 403 if the origin is not allowed or if it request a non allowed header in Access-Control-Request-Headers

🤔 ah yeah indeed, when I tried I got a 403, because I was not_authenticated but let me add a proper error handler for this.

Updated. Let me know if this is what you had in mind.

tdraier

just missing the origin.startsWith(DEV_ORIGIN) instead of === , but looks good 👍

spolu

Let's a few comments. Nitpicky but this is high security risk.

I remember we had cors stuff in next config or our infra? Did you clean them up?

Surprised that there isn't a lib for that? When it comes to security a lib from trusted providers is always better than custom code, did you check?

spolu · 2025-03-21T07:37:31Z

front/middleware.ts

+  response: NextResponse,
+  request: NextRequest
+): NextResponse {
+  const corsResponse = setCorsHeaders(response, request);


Let's call it corsErrorResponse

spolu · 2025-03-21T07:39:01Z

front/middleware.ts

+    ?.toLowerCase();
+
+  // If this is a preflight request checking headers.
+  if (request.method === "OPTIONS" && requestHeaders) {


If OPTIONS and no header we should 403 as well instead of blanket 200?

My understanding was that an OPTIONS request without CORS-specific headers is likely a regular HTTP OPTIONS request (checking which HTTP methods are supported). These are valid HTTP requests that should receive a 200 OK with appropriate Allow headers

spolu · 2025-03-21T07:40:04Z

front/middleware.ts

+
+  response.headers.set(
+    "Access-Control-Allow-Methods",
+    "GET, POST, PUT, DELETE, OPTIONS"


Should we put OPTIONS here?

See comment from above.

spolu · 2025-03-21T07:40:56Z

front/config/cors.ts

+  "content-type",
+  "x-request-origin",
+  "x-commit-hash",
+  "x-dust-extension-version",


We also allow a header for hacker one researchers (see our vdp documentation)

Good catch, added.

spolu · 2025-03-21T07:41:38Z

front/middleware.ts

+  // Cannot use helper functions like isDevelopment() in Edge Runtime middleware since they are not
+  // bundled. Must check NODE_ENV directly.
+  const isDevOrigin =
+    process.env.NODE_ENV === "development" && origin === DEV_ORIGIN;


We can get rid of DEV_ORIGIN no? Less code is better for security we just allow all in dev

flvndvd · 2025-03-21T09:08:24Z

I remember we had cors stuff in next config or our infra? Did you clean them up?
As far as I remember we did not have any.

Surprised that there isn't a lib for that? When it comes to security a lib from trusted providers is always better than custom code, did you check?

I did check for existing libraries, all of them are for expressJS, I found only one for NextJs that did not convince me.

Most resources out there will tell you to use the middleware approach for NextJs (example).

spolu

LGTM

This reverts commit f03c150.

flvndvd added 3 commits March 20, 2025 21:46

Add support for CORS on our public API

1107a23

✨

a3a88a4

✨

70cb19f

flvndvd marked this pull request as ready for review March 20, 2025 20:53

✨

297448c

tdraier reviewed Mar 20, 2025

View reviewed changes

Improve CORS handling

6857ead

tdraier approved these changes Mar 20, 2025

View reviewed changes

spolu reviewed Mar 21, 2025

View reviewed changes

Feedback

bffa4a1

spolu approved these changes Mar 21, 2025

View reviewed changes

flvndvd merged commit f03c150 into main Mar 21, 2025
6 checks passed

flvndvd deleted the flav/public-api-cors branch March 21, 2025 10:03

flvndvd added a commit that referenced this pull request Mar 21, 2025

Revert "CORS Configuration for Public API (#11512)"

d4b4afb

This reverts commit f03c150.

This was referenced Mar 21, 2025

Revert "CORS Configuration for Public API" #11522

Closed

CORS Issue with Public API #11523

Merged

flvndvd restored the flav/public-api-cors branch March 21, 2025 13:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CORS Configuration for Public API #11512

CORS Configuration for Public API #11512

flvndvd commented Mar 20, 2025 •

edited

Loading

tdraier Mar 20, 2025

flvndvd Mar 20, 2025

tdraier Mar 20, 2025

flvndvd Mar 20, 2025

tdraier Mar 20, 2025

flvndvd Mar 20, 2025

flvndvd Mar 20, 2025

tdraier left a comment

spolu left a comment

spolu Mar 21, 2025

spolu Mar 21, 2025

flvndvd Mar 21, 2025

spolu Mar 21, 2025

flvndvd Mar 21, 2025

spolu Mar 21, 2025

flvndvd Mar 21, 2025

spolu Mar 21, 2025

flvndvd Mar 21, 2025

flvndvd commented Mar 21, 2025

spolu left a comment

CORS Configuration for Public API #11512

CORS Configuration for Public API #11512

Conversation

flvndvd commented Mar 20, 2025 • edited Loading

Context

Problem

Solution

Changes

CORS Configuration

Middleware Updates

Technical Details

Tests

Risk

Deploy Plan

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tdraier left a comment

Choose a reason for hiding this comment

spolu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flvndvd commented Mar 21, 2025

spolu left a comment

Choose a reason for hiding this comment

flvndvd commented Mar 20, 2025 •

edited

Loading