# How Cross-Origin Resource Sharing (CORS) Configuration Works in MiniSearch Server Hooks

> Learn how MiniSearch implements CORS configuration using custom Vite server hooks and cross-origin isolation headers for enhanced security and SharedArrayBuffer support.

- Repository: [Victor Nogueira/minisearch](https://github.com/felladrin/minisearch)
- Tags: how-to-guide
- Published: 2026-03-01

---

**MiniSearch implements cross-origin resource sharing (CORS) configuration through a custom Vite server hook that enforces cross-origin isolation headers rather than traditional Access-Control-Allow-* directives, enabling browser features like SharedArrayBuffer while maintaining strict security policies.**

The felladrin/minisearch repository handles cross-origin resource sharing (CORS) configuration through a specialized server-side approach within its Vite-based architecture. Instead of relying on conventional CORS middleware, the project uses a dedicated hook to apply cross-origin isolation policies at the HTTP layer. This strategy ensures every response includes the security headers required to unlock powerful web platform features without exposing the application to cross-origin vulnerabilities.

## Cross-Origin Isolation vs Traditional CORS Headers

MiniSearch does not use the typical `Access-Control-Allow-Origin` mechanism found in standard CORS configurations. Because the public API is served from the same origin as the Vite development server, traditional cross-origin access permissions are unnecessary. Instead, the implementation focuses on **cross-origin isolation**, a stricter security model that allows browsers to expose sensitive APIs such as `SharedArrayBuffer` while preventing cross-origin attacks.

The isolation strategy relies on three specific HTTP response headers that control how the browser handles cross-origin resources and browsing contexts. These headers are injected via middleware in the server hook rather than through Vite's default CORS settings.

## The crossOriginServerHook Implementation

The core logic resides in [`server/crossOriginServerHook.ts`](https://github.com/felladrin/minisearch/blob/main/server/crossOriginServerHook.ts), where the `crossOriginServerHook` function registers middleware on the Vite server instance. This hook accepts either a `ViteDevServer` or `PreviewServer` and attaches a request handler that executes on every incoming connection.

According to the source code at lines 8-25, the middleware constructs an array of isolation headers and applies them to each response using `response.setHeader`:

```typescript
// server/crossOriginServerHook.ts
export function crossOriginServerHook<T extends ViteDevServer | PreviewServer>(server: T) {
  server.middlewares.use((_, response, next) => {
    const headers = [
      { key: "Cross-Origin-Embedder-Policy", value: "require-corp" },
      { key: "Cross-Origin-Opener-Policy", value: "same-origin" },
      { key: "Cross-Origin-Resource-Policy", value: "cross-origin" },
    ];

    for (const { key, value } of headers) {
      response.setHeader(key, value);
    }
    next();
  });
}

```

At line 27, the middleware calls `next()` to pass control down the chain after setting the headers. The three headers serve distinct purposes:

- **Cross-Origin-Embedder-Policy: require-corp** blocks resources that lack explicit cross-origin permissions
- **Cross-Origin-Opener-Policy: same-origin** isolates the browsing context from cross-origin windows
- **Cross-Origin-Resource-Policy: cross-origin** explicitly allows cross-origin usage of the resource

## Registering the Hook in Vite Configuration

The server hook requires explicit registration within the Vite plugin configuration to activate for both development and production preview environments. In [`vite.config.ts`](https://github.com/felladrin/minisearch/blob/main/vite.config.ts) (lines 101-106), the `crossOriginServerHook` is attached via the `configureServer` and `configurePreviewServer` lifecycle hooks:

```typescript
// vite.config.ts (excerpt)
import { crossOriginServerHook } from "./server/crossOriginServerHook";

export default defineConfig(({ command }) => ({
  plugins: [
    {
      name: "configure-server-cross-origin-isolation",
      configureServer: crossOriginServerHook,
      configurePreviewServer: crossOriginServerHook,
    },
  ],
}));

```

This dual registration ensures that whether running `vite dev` or `vite preview`, every response served by MiniSearch includes the isolation headers required for cross-origin isolated contexts.

## Verifying the Configuration

You can verify that the CORS configuration is active by inspecting the response headers from the running server. When the Vite server is operational, all HTTP responses include the three cross-origin isolation headers:

```bash
curl -I http://localhost:5173/

```

The output should display:

```text
HTTP/1.1 200 OK
cross-origin-embedder-policy: require-corp
cross-origin-opener-policy: same-origin
cross-origin-resource-policy: cross-origin

```

This confirms that the `crossOriginServerHook` middleware is correctly injecting the headers as implemented in the felladrin/minisearch source code.

## Summary

- MiniSearch uses **cross-origin isolation** rather than traditional CORS headers to secure the application and enable high-performance APIs
- The `crossOriginServerHook` function in [`server/crossOriginServerHook.ts`](https://github.com/felladrin/minisearch/blob/main/server/crossOriginServerHook.ts) injects three security headers on every response (lines 8-25)
- Headers include **Cross-Origin-Embedder-Policy**, **Cross-Origin-Opener-Policy**, and **Cross-Origin-Resource-Policy**
- Registration occurs in [`vite.config.ts`](https://github.com/felladrin/minisearch/blob/main/vite.config.ts) through both `configureServer` and `configurePreviewServer` hooks (lines 101-106)
- This configuration satisfies browser requirements for `SharedArrayBuffer` while maintaining strict origin boundaries

## Frequently Asked Questions

### What is the difference between cross-origin isolation and traditional CORS?

Traditional CORS uses `Access-Control-Allow-Origin` headers to permit cross-origin requests from specific domains. Cross-origin isolation, as implemented in felladrin/minisearch, uses `Cross-Origin-Embedder-Policy` and related headers to create a secure context that isolates the application from other origins while enabling powerful features like `SharedArrayBuffer`. The latter approach is stricter and does not rely on origin allowlists.

### Why does MiniSearch use cross-origin isolation instead of standard CORS headers?

The project serves its public API from the same origin as the Vite server, eliminating the need for cross-origin request permissions. However, to utilize `SharedArrayBuffer` and similar high-performance APIs, browsers require a cross-origin isolated context. The three headers set by `crossOriginServerHook` satisfy this requirement without exposing the application to the security risks of permissive CORS policies.

### How do I verify that the CORS configuration is working correctly?

Use `curl -I http://localhost:5173/` or check the Network tab in browser DevTools for any request to the MiniSearch server. Look for the presence of `cross-origin-embedder-policy: require-corp`, `cross-origin-opener-policy: same-origin`, and `cross-origin-resource-policy: cross-origin` in the response headers. Their presence confirms the server hook is functioning as defined in [`server/crossOriginServerHook.ts`](https://github.com/felladrin/minisearch/blob/main/server/crossOriginServerHook.ts).

### Can I modify the headers to allow specific external origins?

While the current implementation in [`server/crossOriginServerHook.ts`](https://github.com/felladrin/minisearch/blob/main/server/crossOriginServerHook.ts) applies uniform headers to all responses, you could extend the middleware to conditionally set headers based on request origin. However, modifying the cross-origin isolation policy requires careful consideration, as relaxing `Cross-Origin-Embedder-Policy` or `Cross-Origin-Opener-Policy` would break the isolated context required for `SharedArrayBuffer` and similar APIs.