CORS பிழைகளை எப்படிச் சரிசெய்வது (அவை ஏன் நடக்கின்றன)

CORS பிழை என்பது உங்கள் வலைப் பக்கம் வேறு origin-இலிருந்து (வேறு domain, port அல்லது protocol) ஒரு பதிலைப் படிக்க முயன்றது, அந்த சர்வர் அது அனுமதிக்கப்பட்டது என்று சொல்லும் headers அனுப்பவில்லை என்பதைக் குறிக்கிறது. பயனர்களைப் பாதுகாக்க உலாவிகள் அந்த பதிலைத் தடுக்கின்றன. நீங்கள் சர்வரில் சரிசெய்கிறீர்கள்: உங்கள் தளத்தின் origin-க்கு Access-Control-Allow-Origin header-ஐத் திருப்பி, OPTIONS preflight கோரிக்கைகளைக் கையாண்டு; அல்லது அதே origin-இல் உள்ள உங்கள் சொந்த backend வழியாகக் கோரிக்கையை அனுப்பி அதைத் தவிர்க்கிறீர்கள்.

கோரிக்கை பெரும்பாலும் சர்வரை சரியாக அடைவதால், வலை மேம்பாட்டில் இது மிகவும் குழப்பும் பிழைகளில் ஒன்று. இந்த வழிகாட்டி என்ன நடக்கிறது என்பதையும், ஒவ்வொரு வகையையும் எப்படிச் சரிசெய்வது என்பதையும் விளக்குகிறது.

"Origin" என்றால் என்ன

Origin என்பது protocol, domain மற்றும் port ஆகியவற்றின் கலவை:

URL	Origin
`https://myapp.com/dashboard`	`https://myapp.com`
`https://api.myapp.com/users`	`https://api.myapp.com` (வேறு subdomain, எனவே வேறு origin)
`http://localhost:5173`	`http://localhost:5173`
`http://localhost:3000`	`http://localhost:3000` (வேறு port, எனவே வேறு origin)

உலாவிகள் same-origin policy-ஐப் பின்பற்றுகின்றன: ஒரு பக்கத்தில் உள்ள JavaScript தன் சொந்த origin-இலிருந்து வரும் பதில்களை சுதந்திரமாகப் படிக்கலாம், ஆனால் மற்றவற்றிலிருந்து அல்ல. CORS (Cross-Origin Resource Sharing) என்பது ஒரு சர்வர் ஒப்புக்கொள்ள அனுமதிக்கும் அமைப்பு: "இந்த origins-இலிருந்து வரும் பக்கங்கள் என் பதில்களைப் படிக்கலாம்."

மக்களை ஆச்சரியப்படுத்தும் இரண்டு விளைவுகள்:

கோரிக்கை பெரும்பாலும் சர்வரை அடைகிறது. CORS பொதுவாக உங்கள் குறியீடு பதிலை படிப்பதை தடுக்கிறது, சர்வர் கோரிக்கையைப் பெறுவதை அல்ல. பிழையைப் பார்த்தாலும் ஒரு POST சேமிக்கப்பட்டிருக்கலாம்.
உலாவிகள் மட்டுமே அமல்படுத்துகின்றன. curl, Postman மற்றும் சர்வர்-பக்க குறியீடு CORS-ஐ முற்றிலும் புறக்கணிக்கின்றன. அதனால்தான் "Postman-இல் வேலை செய்கிறது" என்பது CORS பற்றி எதையும் சொல்வதில்லை.

படி 1: சரியான பிழையைப் படியுங்கள்

Developer tools-ஐத் திறவுங்கள் (வலது-கிளிக் → Inspect), Console-க்குச் சென்று முழுச் செய்தியைப் படியுங்கள். Chrome-இன் சொல்லாட்சி உங்களுக்கு எந்தச் சிக்கல் என்று சொல்லும்:

செய்தியில் உள்ளது	என்ன தவறு
`No 'Access-Control-Allow-Origin' header is present`	சர்வர் அந்த header-ஐ அனுப்பவில்லை, அல்லது உங்கள் CORS குறியீட்டை அடைவதற்கு முன்பே கோரிக்கை தோல்வியடைந்தது (எடுத்துக்காட்டாக 404 அல்லது 500)
`The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin`	சர்வர் உங்களுடையதல்லாத வேறு origin-ஐ அனுமதிக்கிறது
`Response to preflight request doesn't pass access control check`	`OPTIONS` preflight தோல்வியடைந்தது
`...must not be the wildcard '*' when the request's credentials mode is 'include'`	நீங்கள் cookies அனுப்புகிறீர்கள், ஆனால் சர்வர் `*` என்று பதிலளித்தது
`Request header field authorization is not allowed`	சர்வர் அந்த header-ஐ `Access-Control-Allow-Headers`-இல் பட்டியலிடவில்லை

பிறகு Network tab-ஐத் திறந்து, தோல்வியடைந்த கோரிக்கையையும் (அதற்கு முன் வரும் எந்த OPTIONS கோரிக்கையையும்) கண்டறிந்து, அதன் status code மற்றும் பதில் headers-ஐப் பாருங்கள்.

முதலில் status code-ஐச் சரிபாருங்கள். பல "CORS பிழைகள்" உண்மையில் மறைமுகமான சர்வர் பிழைகள். சர்வர் செயலிழந்தாலோ 404 தந்தாலோ, அதன் பிழைப் பதிலில் பெரும்பாலும் CORS headers இருக்காது, எனவே உலாவி உண்மையான சிக்கலுக்குப் பதிலாக CORS என்று அறிவிக்கிறது. 500 அல்லது 404-ஐச் சரிசெய்தால், CORS பிழை மறையலாம்.

படி 2: அந்த API-ஐ உலாவியிலிருந்தே அழைக்க வேண்டுமா என்று முடிவு செய்யுங்கள்

Headers சேர்ப்பதற்கு முன் கேளுங்கள்: உலாவி இந்த API-ஐ நேரடியாக அழைக்க வேண்டுமா?

Secret key தேவைப்படும் மூன்றாம் தரப்பு API (OpenAI, Stripe secret key, பெரும்பாலான மின்னஞ்சல் சேவைகள்) உலாவியிலிருந்து ஒருபோதும் அழைக்கப்படக்கூடாது. Key ஒவ்வொரு பார்வையாளருக்கும் தெரியும். அதற்குப் பதிலாக உங்கள் backend-இலிருந்து அழையுங்கள்; அப்போது CORS பிரச்சனை மறையும், ஏனெனில் சர்வர்-இலிருந்து-சர்வருக்கான கோரிக்கைகள் CORS-க்கு உட்பட்டவை அல்ல. API keys-ஐப் பாதுகாப்பாக வைப்பது எப்படி பாருங்கள்.
நீங்கள் கட்டுப்படுத்தாத மூன்றாம் தரப்பு API CORS headers அனுப்பவில்லையென்றால் உங்கள் பக்கத்திலிருந்து சரிசெய்ய முடியாது. உங்கள் backend-இலிருந்து அழையுங்கள்.
உங்கள் சொந்த API சரியாக அமைப்பதன் மூலம் சரிசெய்யலாம். கீழே தொடரவும்.

படி 3: உங்கள் சர்வரில் சரிசெய்யுங்கள்

சர்வர் தனது பதில்களுக்கு, பிழைப் பதில்கள் உட்பட, சரியான headers-ஐச் சேர்க்க வேண்டும்.

உண்மையான கோரிக்கைக்கு, அனுப்புங்கள்:

Access-Control-Allow-Origin: https://myapp.com (உங்கள் frontend-இன் சரியான origin, இறுதியில் slash இல்லாமல்)
மதிப்பு எந்த origin கேட்டது என்பதைப் பொறுத்திருந்தால் Vary: Origin

Preflight OPTIONS கோரிக்கைக்கு, வெற்றி நிலையுடன் (200 அல்லது 204) பதிலளித்து:

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization (நீங்கள் அனுப்பும் ஒவ்வொரு custom header-உம்)
விருப்பமாக Access-Control-Max-Age: 600, அதனால் உலாவி preflight-ஐ சிறிது நேரம் cache செய்யும்

பெரும்பாலான frameworks-க்கு இதைச் செய்யும் package அல்லது அமைப்பு உள்ளது. Express-இல் cors package; FastAPI-இல் CORSMiddleware; ASP.NET Core-இல் AddCors; Spring-இல் @CrossOrigin அல்லது CORS configuration. ஒரு பொதுவான Express அமைப்பு:

import cors from "cors";

app.use(cors({
  origin: ["https://myapp.com", "http://localhost:5173"],
  credentials: true,
}));

CORS கையாளுதலை உங்கள் routes மற்றும் authentication-க்கு முன் வையுங்கள், அதனால் login இல்லாமல் வரும் preflight கோரிக்கைகள் 401 உடன் நிராகரிக்கப்படாது.

AI builder-உடன், அமைப்பை துல்லியமாக விவரியுங்கள்:

https://myapp.com-இல் உள்ள frontend https://api.myapp.com API-ஐ அழைக்கிறது, "Response to preflight request doesn't pass access control check" பிழை வருகிறது. API-இல் CORS-ஐ சரியாக https://myapp.com மற்றும் preview origin-க்கு மட்டும் அனுமதிக்கும்படி அமை, Content-Type மற்றும் Authorization headers உடன் GET, POST, PATCH, DELETE அனுமதி, auth-க்கு முன் OPTIONS-ஐக் கையாளு, பிழைப் பதில்களிலும் CORS headers சேர்.

படி 4: cookies மற்றும் credentials-ஐக் கையாளுங்கள்

உங்கள் frontend ஒரு வேறு origin-க்கு cookies (எடுத்துக்காட்டாக ஒரு login session) அனுப்பினால், இரு தரப்பும் ஒப்புக்கொள்ள வேண்டும்:

Frontend fetch-இல் credentials: "include" அமைக்கிறது, அல்லது axios-இல் withCredentials: true.
சர்வர் Access-Control-Allow-Credentials: true அனுப்புகிறது.
சர்வரின் Access-Control-Allow-Origin சரியான origin ஆக இருக்க வேண்டும், * அல்ல.

குறுக்கு-தளம் cookies-க்கு cookie-இல் SameSite=None; Secure தேவை, மேலும் சில உலாவிகள் மூன்றாம் தரப்பு cookies-ஐ இன்னும் கட்டுப்படுத்துகின்றன. படி 5-இல் உள்ள அணுகுமுறையை விரும்ப இன்னொரு காரணம் இது.

படி 5: same-origin அமைப்புடன் CORS-ஐத் தவிர்க்கவும்

பெரும்பாலும் சிறந்த தீர்வு, origin-களைக் கடக்கும் கோரிக்கைகளையே உருவாக்காமல் இருப்பது. பக்கத்தின் அதே origin-இலிருந்து API-ஐ வழங்குங்கள், எடுத்துக்காட்டாக https://myapp.com/api/...-இல்:

Development-இல், பெரும்பாலான dev servers proxy செய்யலாம். Vite-இன் server.proxy அமைப்பு /api-ஐ வேறு port-இல் உள்ள உங்கள் backend-க்கு அனுப்ப முடியும், அதனால் உலாவி ஒரே origin-உடன் மட்டுமே பேசும்.
Production-இல், உங்கள் ஹோஸ்டின் rewrite அல்லது proxy அமைப்புகள் மூலம் /api-ஐ backend-க்கு route செய்யுங்கள், அல்லது frontend மற்றும் API-ஐ ஒரே சர்வரிலிருந்து வழங்குங்கள்.

பின்னர் frontend fetch("/api/orders") போன்ற உறவுப் பாதையை அழைக்கிறது. Cross-origin கோரிக்கை இல்லை, origins-க்கு இடையிலான preflight இல்லை, cookie தலைவலிகளும் இல்லை. Preview மற்றும் production-க்கு இடையே வேறுபடும் API domain-ஐ நீங்கள் கடினக் குறியீடு செய்ய வேண்டியதில்லை என்றும் இது பொருள்.

Frontend முழு URL-க்குப் பதிலாக உறவுப் /api பாதைகள் மூலம் backend-ஐ அழைக்கும்படி மாற்று, /api API சர்வருக்கு அனுப்பப்படுமாறு dev proxy அமை. பின்னர் இனி தேவைப்படாத CORS அமைப்புகளை நீக்கு.

செய்யக்கூடாதவை

fetch-இல் mode: "no-cors". அது எதையும் தாண்டுவதில்லை; அது உங்கள் குறியீட்டுக்கு வெற்று, படிக்க முடியாத பதிலைத் தருகிறது.
CORS-ஐ முடக்கும் உலாவி நீட்டிப்புகள். அவை உங்கள் உலாவியை மட்டுமே மாற்றுகின்றன. ஒவ்வொரு பார்வையாளரும் இன்னும் பிழையைப் பார்ப்பார்கள்.
உண்மையான ஆப்களுக்கு பொது "CORS proxy" சேவைகள். அவை வழியாகச் செல்லும் அனைத்தையும் படிக்கவும் மாற்றவும் முடியும், மேலும் அவை செயலிழக்கின்றன.
Login பயன்படுத்தும் API-இல் Access-Control-Allow-Origin: *. அது credentials உடன் எப்படியும் வேலை செய்யாது, தனிப்பட்ட தரவுக்கு தவறான இயல்புநிலை.
Credentials அனுமதிக்கப்பட்ட நிலையில் எந்த Origin header-ஐயும் திருப்பி பிரதிபலிப்பது. அது எந்த வலைத்தளமும் உங்கள் பயனர்கள் சார்பாக login செய்யப்பட்ட கோரிக்கைகளைச் செய்ய அனுமதிக்கும். அனுமதிப் பட்டியலைப் (allowlist) பயன்படுத்துங்கள்.

AI மூலம் உருவாக்கிய ஆப்களில் பொதுவான காரணங்கள்

சூழ்நிலை	தீர்வு
Frontend secret key உள்ள மூன்றாம் தரப்பு API-ஐ அழைக்கிறது	அழைப்பை backend-க்கு நகர்த்துங்கள்
Preview-இல் வேலை செய்கிறது, வெளியிடப்பட்ட domain-இல் தோல்வி	வெளியிடப்பட்ட மற்றும் custom-domain origins-ஐ அனுமதிப் பட்டியலில் சேருங்கள், அல்லது உறவுப் `/api` பாதைகளைப் பயன்படுத்துங்கள்
POST, PUT அல்லது DELETE-இல் மட்டும் பிழை	Preflight கையாளப்படவில்லை; `OPTIONS` கையாளுதலையும் அனுமதிக்கப்பட்ட headers-ஐயும் சேருங்கள்
Login சேர்த்த பின் பிழை வந்தது	Credentials-க்கு சரியான origin மற்றும் `Allow-Credentials` தேவை
"CORS பிழை" ஆனால் Network tab 500 காட்டுகிறது	முதலில் சர்வர் பிழையைச் சரிசெய்யுங்கள்
API URL `localhost`-க்கு கடினக் குறியீடு செய்யப்பட்டுள்ளது	உறவுப் பாதைகள் அல்லது சூழலுக்கு ஏற்ற அமைப்பைப் பயன்படுத்துங்கள்

Mythex-இல் CORS

Mythex திட்டத்தில் ஒரு வலைத்தளமும் API சர்வரும் இருக்கும்போது, இரண்டும் ஒரே திட்டத்தில் services-ஆக இயங்குகின்றன, preview-வில் நீங்கள் அவற்றுக்கு இடையே மாறலாம். Frontend backend-ஐ உறவுப் /api பாதை மூலம் அழைக்கும்படி agent-இடம் கேட்பது — development-இல் proxy செய்யப்பட்டு — பெரும்பாலான CORS சிக்கல்களைத் தவிர்க்கிறது. குறுக்கு-origin அழைப்புகள் உண்மையில் தேவைப்பட்டால், console-இலிருந்து சரியான பிழையையும் சம்பந்தப்பட்ட origins-ஐயும் agent-க்குக் கொடுங்கள். அதன் முகவரி preview-இலிருந்து வேறுபடுவதால், வெளியிடப்பட்ட ஆப்பிலும் முடிவைச் சரிபாருங்கள். ஆவணங்களில் Multi-service apps மற்றும் API backends பாருங்கள், மேலும் எங்கள் AI-உருவாக்கிய ஆப்பை debug செய்வது மற்றும் frontend vs backend வழிகாட்டிகளையும் பாருங்கள்.

CORS சரிபார்ப்புப் பட்டியல்

முழு console பிழையையும் தோல்வியடைந்த கோரிக்கையின் status code-ஐயும் படித்தாயிற்று
மறைந்திருக்கும் 404 அல்லது 500 நீக்கப்பட்டது
Secret-key APIs உலாவியிலிருந்து அல்ல, backend-இலிருந்து அழைக்கப்படுகின்றன
சர்வர் சரியான அனுமதிக்கப்பட்ட origins-உடன் Access-Control-Allow-Origin அனுப்புகிறது
OPTIONS preflight அனுமதிக்கப்பட்ட methods மற்றும் headers-உடன், auth-க்கு முன் பதிலளிக்கப்படுகிறது
பிழைப் பதில்களிலும் CORS headers உள்ளன
Credentials: சரியான origin, Allow-Credentials: true, சரியான cookie அமைப்புகள்
Preview, வெளியிடப்பட்ட மற்றும் custom-domain origins அனைத்தும் உள்ளடக்கப்பட்டுள்ளன, அல்லது உறவுப் /api பாதைகள் பயன்படுத்தப்படுகின்றன
no-cors, பொது proxies, அல்லது எந்த origin-ஐயும் பிரதிபலிக்கும் குறுக்குவழிகள் இல்லை

கேள்விகள்

CORS பிழை என்றால் என்ன?

ஒரு origin-இலிருந்து ஏற்றப்பட்ட உங்கள் பக்கம், வேறு origin-இலிருந்து ஒரு பதிலைப் படிக்க முயன்றது, அந்த சர்வரின் பதிலில் அனுமதிக்கும் headers இல்லை. உங்கள் குறியீடு பதிலைப் படிப்பதை உலாவி தடுக்கிறது. தீர்வு சர்வரில் உள்ளது, அல்லது கோரிக்கை எப்படி route செய்யப்படுகிறது என்பதில் உள்ளது; frontend குறியீட்டில் அல்ல.

Frontend-இலிருந்து CORS பிழையை சரிசெய்ய முடியுமா?

சரியாக முடியாது. mode: 'no-cors' போன்ற அமைப்புகள் பதிலை உங்கள் குறியீட்டிலிருந்து மறைக்க மட்டுமே செய்கின்றன. சர்வர் சரியான Access-Control-Allow-Origin header-ஐ அனுப்பும்படி செய்வதன் மூலமோ, அல்லது உங்கள் சொந்த backend அல்லது same-origin proxy மூலம் API-ஐ அழைப்பதன் மூலமோ சரிசெய்கிறீர்கள்.

Access-Control-Allow-Origin: * பாதுகாப்பானதா?

யார் வேண்டுமானாலும் படிக்கக்கூடிய பொதுத் தரவுக்கு, login இல்லாத ஒரு பொது API போன்றவற்றுக்கு இது சரி. Cookies அல்லது பிற credentials உடன் இதைப் பயன்படுத்த முடியாது; தனிப்பட்ட APIs-க்கு அனுமதிக்கப்பட்ட சரியான origins-ஐப் பட்டியலிட வேண்டும்.

என் கோரிக்கை Postman அல்லது curl-இல் வேலை செய்கிறது, ஆனால் உலாவியில் ஏன் வேலை செய்யவில்லை?

CORS உலாவிகளால் மட்டுமே அமல்படுத்தப்படுகிறது. Postman மற்றும் curl போன்ற கருவிகள் அதைப் பயன்படுத்துவதில்லை, அதனால் அங்கு கோரிக்கை வெற்றி பெறலாம், ஆனால் பக்கத்தின் JavaScript அதைச் செய்யும்போது உலாவி அதைத் தடுக்கலாம்.

Preflight கோரிக்கை என்றால் என்ன?

JSON POST அல்லது Authorization header உள்ள கோரிக்கைகள் போன்ற எளிமையற்ற கோரிக்கைகளுக்கு, உலாவி முதலில் எந்த methods மற்றும் headers அனுமதிக்கப்படுகின்றன என்று சர்வரிடம் கேட்க ஒரு OPTIONS கோரிக்கை அனுப்புகிறது. அந்த OPTIONS கோரிக்கை தோல்வியடைந்தாலோ சரியான headers இல்லாவிட்டாலோ, உண்மையான கோரிக்கை ஒருபோதும் அனுப்பப்படுவதில்லை.