CORS 란 무엇입니까?
CORS는 Cross Origin Resource Sharing의 약자로, 추가 HTTP 헤더를 사용하여 브라우저에 한 오리진에서 실행 중인 웹 애플리케이션에 다른 출처의 리소스에 대한 액세스 권한을 부여하도록 지시합니다. 예를 들어 프런트 엔드가 백엔드와 다른 플랫폼에서 호스팅 되는 경우 여기에서 데이터를 가져 오기 위해 HTTP 요청을 해야 합니다. 브라우저는 기본적으로 차단합니다 (동일하지 않은 교차 출처에서 호스팅 됨). 유래). 이는 CSRF 공격으로부터 고객을 보호하기 위해 취하는 보안 조치입니다. 이것이 CORS의 개념이 들어오는 곳입니다.
이제 이번 주에 저를 방해 한 모든 CORS 오류와 각 오류를 수정하는 방법을 알려 드리겠습니다.
Access Control Allow Origin 헤더가 없습니다.
cors에 대해 완전히 알 수 없었기 때문에 Express 앱을 작성하고 React의 package.json에 프록시를 추가하여 개발 중인 백엔드 경로에 액세스했습니다. 그러나 프로덕션으로 이동하면 앱이 로딩 상태를 유지하고 콘솔에 이러한 오류가 표시되었습니다.
내 오류의 스크린 샷을 캡처 할 수 없어 경로가 달랐지만 메시지는 동일했습니다. 내 제품이 성공했고 모든 것이 로컬에서 작동했지만 온라인으로 작동하지 않았습니다.
우리의 오리진이 CORS 정책에 의해 차단되어 백엔드에서 데이터에 액세스 할 수 없다고 말하는 것입니다. 또한 어떤 출처에서 데이터에 액세스 할 수 있는지 알려주는 HTTP 헤더가 있는 Access-Control-Allow-Origin 헤더가 없습니다. 요청시 모든 데이터를 보낼 수 있도록 프런트 엔드 엔드 포인트를 추가해야 합니다.
Fix
언급 된 HTTP 헤더를 서버의 응답에 추가하여 더 이상 이러한 오류가 발생하지 않도록 할 수 있습니다. 서버의 루트 파일에 이것을 추가하면 쉽게 할 수 있습니다.
app.use((req, res, next) => {
res.header("Access-Control-Allow-Origin", "*");
next();
});*는 모든 출처 (웹 사이트)가 서버에 요청을 할 수 있도록 허용하는 와일드 카드이며 더 이상 이러한 CORS 오류를 발생 시키지 않습니다.
응답의 액세스 제어 허용 원본 헤더는 와일드 카드가 아니어야 합니다. *
문제는 요청에 쿠키와 같은 자격 증명을 보내는 경우 withCredentials : true (axios) 또는 자격 증명 : 'include'(가져 오기)가 있다는 의미입니다. 그러면 오류가 발생하여 요청이 다시 차단됩니다. 이 같은.
아래에서 읽을 수 없는 경우 실제 오류 메시지입니다.
The value of the `Access-Control-Allow-Origin` header in the response must not be the wildcard `*` when the request's credentials mode is `include`. Origin is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.이는 서버가 사용자로부터 쿠키와 같은 특정 자격 증명을 얻을 때 모든 출처의 요청을 허용하지 않으므로 CORS에 의해 다시 차단됩니다.
Fix
* 대신 API에 액세스 할 수 있는 프런트 엔드 URL 또는 다른 웹 사이트를 추가하기 만하면 됩니다. 둘 이상인 경우 쉼표로 구분하십시오.
실행 전 요청에 대한 응답이 액세스 제어 확인을 통과하지 못함
프리 플라이트 란 무엇입니까?
CORS 프로토콜을 이해하고 원래 요청을 보내는 것이 안전한지 확인하기 위해 실행 전 요청이 작성됩니다. DELETE, PUT 또는 데이터를 수정할 수 있고 CORS 허용 목록에 없는 요청 헤더가 있는 기타 메서드와 같은 요청은 이 프리 플라이트 요청을 만들 수 있습니다. 3 개의 HTTP 요청 헤더를 사용하는 OPTIONS 요청입니다. Access-Control-Request-Method, Access-Control-Request-Headers, Origin은이 MDN 문서를 참조하세요.
백엔드가 프리 플라이트를 활성화하지 않은 경우 표시되는 오류 메시지입니다.
Fix
OPTIONS 요청을 받으면 허용 된 모든 HTTP 메서드와 응답 상태가 200 인 응답 Access-Control-Allow-Methods 헤더를 다시 보내 쉽게 수정할 수 있습니다. 이제 미들웨어에 추가해 보겠습니다.
app.use((req, res, next) => {
if (req.method === "OPTIONS") {
res.header("Access-Control-Allow-Methods", "PUT, POST, PATCH, DELETE, GET");
return res.status(200).json({});
}
next();
});응답의 액세스 제어 Allow Credentials 헤더는 ''이며 요청 자격 증명 모드가 'include'인 경우 'true'여야 합니다.
Access Control Allow Credentials는 앱이 쿠키와 같은 자격 증명을 사용하여 요청을 보낼 때 표시되어야 하는 헤더이기도 합니다. 이것은 이 헤더가없고 요청과 함께 자격 증명을 보낼 때 받는 메시지입니다.
Fix
위에 표시된 대로 다른 헤더와 함께 이 헤더를 추가 할 수 있습니다.
app.use((req, res, next) => {
res.header("Access-Control-Allow-Credentials", true);
next();
});Pro Tip
익스프레스 / 커넥트를 사용하는 경우 편리한 방식으로 헤더를 추가하는 정확한 작업을 수행하는 준비된 Node.js CORS 미들웨어 패키지가 있습니다. npm install cors로 설치할 수 있습니다.
말 했듯이 설정하기가 너무 쉽기 때문에 기본 cors 기능 만 활성화하면 작성하면 됩니다.
const cors = require("cors");
app.use(cors());구성도 가능하지만 기본 구성은 다음과 같습니다.
{
"origin": "*",
"methods": "GET,HEAD,PUT,PATCH,POST,DELETE",
"preflightContinue": false,
"optionsSuccessStatus": 204
}따라서 기본적으로 :
앱 요구 사항에 따라 구성 할 수 있습니다. 다음은 사용 가능한 옵션 목록입니다.
이것이 내가 내 앱을 위해 선택한 방법입니다.
const origin =
process.env.NODE_ENV === "production"
? process.env.FRONTEND_PROD_URL
: process.env.FRONTEND_LOCAL_URL;
// Setting up cors
app.use(
cors({
origin: origin,
preflightContinue: true,
methods: "GET,HEAD,PUT,PATCH,POST,DELETE",
credentials: true,
})
);자격 증명 키는 Access-Control-Allow-Credentials를 true로 설정합니다. 위에서 설명한 대로 각 헤더를 추가하여 동일한 작업을 수행 할 수도 있습니다.
const origin =
process.env.NODE_ENV === "production"
? process.env.FRONTEND_PROD_URL
: process.env.FRONTEND_LOCAL_URL;
app.use((req, res, next) => {
res.header("Access-Control-Allow-Origin", origin);
res.header("Access-Control-Allow-Credentials", true);
if (req.method === "OPTIONS") {
res.header("Access-Control-Allow-Methods", "PUT, POST, PATCH, DELETE, GET");
return res.status(200).json({});
}
next();
});내 앱이 여전히 콘솔에 CORS 문제를 표시하지만 무엇이 잘못되었는지 모르겠습니다.
이것은 나에게 일어났습니다. 나는 주로 MSFT Edge와 Firefox를 테스트에 사용했기 때문에 두 브라우저 모두에서 내 앱이 환상적으로 작동했습니다. 그러나 내 앱을 확인하기 위해 내가 준 사람들은 CORS 오류가 발생한다고 불평했습니다. 모두 내가 아직 테스트하지 않은 Chrome을 사용하는 것으로 밝혀 졌기 때문에 Chrome을 잡고 살펴 보았습니다. 콘솔에서 위에서 수정 한 두 번째 CORS 문제가 여전히 표시되었습니다. 이런 젠장!
그런 다음 네트워크 탭을 잠시 만지작 거리고 나서 작은 경고 ⚠️ 기호가 제 주의를 끌었습니다.
A cookie associated with a cross-site resource at <url> was set without `SameSite` attribute. It has been blocked, as Chrome now delivers cookies with cross-site requests if they are set with `SameSite=none` and `Secure`.올해 초 (2020 년 2 월) Chrome 80이 출시되면서 기본적으로 안전한 쿠키 분류 시스템이 있으며, 브라우저에서 액세스 할 수 있도록 쿠키에 SameSite 속성이 필요합니다. Lax, Strict, None의 세 가지 값이 있으며 제공하려는 자유에 따라 쿠키를 사용할 것인지 결정해야 합니다.
인터넷 검색을 한 후 heroku의 이 기사가 나왔습니다. Chrome의 변경으로 인해 앱이 손상 될 수 있습니다 : SameSite 쿠키 업데이트 준비가 필요한 이유와 이 속성을 추가하는 방법을 설명했습니다.
여기에 계시는 동안 이 문제를 어떻게 고쳤는지 말씀 드리겠습니다.
Fix
저는 connect-mongo 플러그인을 사용하여 MongoDB에 세션 생성 및 저장을 처리하기 위해 간단한 세션 미들웨어 인 단일 패키지 익스프레스 세션을 사용했습니다. 앱 요구 사항에 대해 cors 패키지와 유사하게 구성 할 수 있습니다.
그래서 내가 해야 할 일은 쿠키 설정에 sameSite 속성을 추가하는 것이었고 완벽하게 작동했습니다.
const session = require("express-session");
const sessionConfig = {
// ... other methods
cookie: {
sameSite: "none",
},
};
if (process.env.NODE_ENV === "production") {
app.set("trust proxy", 1); // trust first proxy
sessionConfig.cookie.secure = true; // serve secure cookies
}
app.use(session(sessionConfig));보안 속성은 프로덕션 환경에서만 true 여야 하므로 HTTPS를 사용하는 출처 만 쿠키에 액세스 할 수 있습니다. 트러스트 프록시는 전면 프록시 서버의 첫 번째 홉을 신뢰하는 1입니다. 자세한 내용은 trust-proxy에 대한 문서를 참조하십시오.
요약 ✨
CORS는 CSRF 공격으로부터 사용자를 보호하는 데 매우 중요하고 유용하며 마찬가지로 Google의 동일한 사이트 속성에 대한 새로운 업데이트 된 정책이 도움이 됩니다. 이틀 동안 계속해서 이러한 일련의 오류가 발생하면 실망스러워 보일 수 있지만 (내가 한) 결국에는 보안 서버와 안전한 인증을 만드는 많은 측면을 알게 되었고 결국 그만한 가치가 있었습니다.
등록된 댓글이 없습니다.
