CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls which websites are allowed to make HTTP requests to a server on a different domain, preventing unauthorized cross-origin data access.
By Vaibhav Jain · Last updated March 27, 2026
Browsers enforce a security policy called the Same-Origin Policy: JavaScript on one domain cannot make requests to a different domain without explicit permission. CORS is the mechanism that grants this permission.
When your form at yoursite.com sends an AJAX request to formslist.com/f/abc123, the browser first checks whether FormsList's server allows requests from yoursite.com. It does this by looking at the Access-Control-Allow-Origin response header. If the header includes yoursite.com (or the wildcard *), the request proceeds. If not, the browser blocks it.
For simple form submissions (traditional HTML form posts), CORS doesn't apply — the browser navigates to the action URL directly. CORS only affects JavaScript-initiated requests (AJAX/Fetch API), which is why it matters for modern single-page applications.
FormsList endpoints include permissive CORS headers (Access-Control-Allow-Origin: *) so that AJAX form submissions work from any domain without additional configuration. If you're building your own form endpoint, you need to set these headers yourself, typically by configuring your web server or adding middleware in your application code.
What is CORS? CORS (Cross-Origin Resource Sharing) is a browser-enforced security mechanism that governs whether JavaScript running on one domain (origin) is allowed to make HTTP requests to a server on a different domain. It is an extension of the browser's Same-Origin Policy, which by default blocks cross-origin requests to prevent malicious websites from accessing data on other sites without authorization. CORS provides a standardized way for servers to declare which external origins are permitted to access their resources, using specific HTTP response headers that the browser checks before allowing the JavaScript code to read the response.
The Same-Origin Policy defines an "origin" as the combination of protocol (http/https), domain (example.com), and port (443). JavaScript running on https://yoursite.com can freely make requests to https://yoursite.com/api, but if it tries to make a fetch() or XMLHttpRequest call to https://formslist.com/f/abc123, the browser intercepts the response and checks for CORS headers. The key header is Access-Control-Allow-Origin, which the server includes in its response to indicate which origins are permitted. If the header's value matches the requesting origin (e.g., Access-Control-Allow-Origin: https://yoursite.com) or uses the wildcard (Access-Control-Allow-Origin: *), the browser allows the JavaScript to read the response. If the header is missing or does not match, the browser blocks the response and throws a CORS error in the console — even though the server successfully received and processed the request.
For form submissions specifically, CORS behavior depends on how the form is submitted. Traditional HTML form submissions (where the browser navigates to the action URL) are not subject to CORS — the browser sends the POST request and navigates to whatever the server responds with, regardless of origin. CORS only applies to JavaScript-initiated requests: fetch(), XMLHttpRequest, and Axios calls. This distinction is important because AJAX form submissions (which keep the user on the same page) are JavaScript-initiated and therefore subject to CORS, while traditional form posts are not. Additionally, certain AJAX requests trigger a CORS "preflight" — an automatic OPTIONS request the browser sends before the actual request to check permissions. Preflight occurs when the request uses certain HTTP methods (PUT, DELETE), includes custom headers, or sets the Content-Type to application/json. The server must respond to the OPTIONS request with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers for the actual request to proceed.
FormsList endpoints include permissive CORS headers on all responses (Access-Control-Allow-Origin: * and appropriate Access-Control-Allow-Methods and Access-Control-Allow-Headers values), so AJAX form submissions from any domain work without additional configuration. This means you can submit forms to FormsList via JavaScript from any website — whether hosted on Vercel, Netlify, GitHub Pages, Shopify, or any other platform — without encountering CORS errors. If you are building your own form endpoint instead, you need to configure CORS headers yourself, either in your web server configuration (Nginx, Apache), your application framework middleware (Express cors() middleware, Django django-cors-headers), or your serverless function response headers. A real-world example: a developer builds a React single-page application hosted on https://app.startup.com with a contact form that submits to FormsList via fetch(). Because FormsList returns Access-Control-Allow-Origin: * in its response headers, the AJAX submission works seamlessly. Later, the developer adds a second form that submits to their own API at https://api.startup.com — they need to add CORS middleware to their Express server to allow requests from https://app.startup.com, or they will see CORS errors in the browser console.
For AJAX POST requests with JSON content type, the browser sends an OPTIONS request first (preflight) to check CORS permissions. The server must respond with appropriate Access-Control-Allow-* headers.
Setting Access-Control-Allow-Origin: * allows any website to make requests to your endpoint. This is appropriate for public form endpoints but not for sensitive APIs.
Setting Access-Control-Allow-Origin to a specific domain (https://yoursite.com) restricts access to only that domain. Multiple origins require server-side logic to check the request origin.
Set up your form backend in under a minute. No server required, no complex configuration — just a simple endpoint for your forms.