CORS 오류가 났는데 서버에는 POST가 들어왔다
CORS 오류가 나도 단순 POST는 서버에 도착하고 처리될 수 있다. 두 loopback 출처에서 응답 공유 헤더 유무와 서버 Origin 거절을 비교해, 요청 수신·실제 변경·응답 읽기를 구분하고 CSRF 방어를 점검할 기준을 설명한다.
빌드노트
웹 보안 카테고리의 글입니다.
총 48개의 글
CORS 오류가 나도 단순 POST는 서버에 도착하고 처리될 수 있다. 두 loopback 출처에서 응답 공유 헤더 유무와 서버 Origin 거절을 비교해, 요청 수신·실제 변경·응답 읽기를 구분하고 CSRF 방어를 점검할 기준을 설명한다.
같은 ‘가’를 나타내는 NFC·NFD 문자열도 UTF-8 바이트가 달라 SHA-256이 다를 수 있다. 실제 Web Crypto 출력으로 이를 확인하고, 양쪽 표현을 통일할 데이터 규약과 원문 바이트를 보존해야 하는 비교를 구분한다.
새 탭의 opener가 null인 이유를 링크의 암묵적 noopener와 window.open 옵션으로 구분한다. 새 프로필에서 다섯 조건을 클릭해 참조·부모 표식·반환값을 비교하고, 보호를 유지할지 통신 계약을 바꿀지 판단한다.
Node PBKDF2의 keylen은 바이트, WebCrypto deriveBits의 length는 비트다. 같은 UTF-8 입력에서 32바이트와 32·256비트를 비교해 단위 변환을 확인하고, 길이를 맞춘 뒤에는 비밀번호·salt·반복 수·해시까지 대조해야 하는 이유를 설명한다.
Node scrypt에서 N을 올린 뒤 매개변수 오류가 나면 호출의 maxmem 예산을 따로 확인한다. 같은 N/r/p에서 32MiB 거절과 64MiB 성공을 비교하고, 유효하지 않은 N과 비동기 호출의 예외 전달을 구별한다.
같은 서버에서 내려받은 iframe도 sandbox가 불투명 원점을 부여하면 부모 DOM에 접근할 수 없다. 다섯 조건의 실제 브라우저 비교로 location.origin·window.origin·메시지 origin을 구별하고, 권한을 추가하기 전에 필요한 통신 범위를 판단한다.
슬래시로 시작하는 returnUrl도 //host나 역슬래시 조합이면 외부로 해석된다. 실제 URL 파싱과 ASP.NET Core helper 결과를 비교하고, 신뢰하는 origin·허용 경로·디코딩 시점과 접근 권한을 구분한다.
HttpOnly 쿠키는 document.cookie에 없어도 HTTP 요청에 실릴 수 있다. 같은 경로의 일반 쿠키와 HttpOnly 쿠키를 실제 브라우저에서 비교하고, 만료 전후와 fetch 옵션에 따른 저장·전송·서버 수신 차이로 확인할 위치를 좁힌다.
AES-GCM 복호화의 OperationError가 나면 키 선택과 IV·AAD·암호문·태그를 호출 직전에서 대조한다. 합성 입력의 정상 복호화와 한 비트 변경 결과를 비교하고, 인증 실패 뒤 문자열 변환이나 평문 처리를 계속하지 않는 방법을 설명한다.
Referer가 없거나 origin만 남아도 요청은 성공할 수 있다. 두 loopback origin에서 네 정책을 비교하고, 수신 헤더와 document.referrer를 나눠 확인해 같은 origin에는 경로·쿼리가 남을 수 있음을 설명한다.
Authorization을 붙인 교차 출처 GET이 실제 전송 전에 막혔는지 OPTIONS 응답과 서버 수신 기록으로 구별한다. 로컬 브라우저에서 OPTIONS 401, 허용 뒤 GET 200, 잘못된 토큰의 GET 401을 비교하고 실제 API 인증을 유지하는 명시적 CORS 정책을 설명한다.
CSP 위반 메시지와 실제 차단은 다를 수 있다. 같은 script-src 정책을 보고전용과 강제 헤더로 보내 DOM 숫자·콘솔을 비교하고, HTML 응답에서 두 헤더와 실제 실행 흔적을 확인하는 방법을 설명한다.