Spring Security + Ajax 호출 시 CSRF 관련 403 Forbidden 에러

Share

Spring Security를 이용할 경우 Ajax의 POST 호출 시 403 Forbidden 에러가 발생합니다. 처음에는 Ajax 문제가 아니라 특정 URL(특히, REST로 만들어진 URL)에 대해 Path 권한 설정이 잘못되었나 생각하고 Path의 권한 설정 부분을 확인하였습니다.

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .csrf()
    .and()
        .addFilterAfter(new CsrfCookieGeneratorFilter(), CsrfFilter.class)
       ...
    .and()
        .authorizeRequests()
        .antMatchers("/news/**").permitAll()
        .antMatchers("/api/**").permitAll();
}

이렇게 permitAll로 설정을 해도 계속 문제가 발생해서 조금 더 코드를 확인해보니 csrf 쪽 관련 문제인 것을 확인했습니다. CSRF는 Cross-site request forgery 라고 해서 사용자가 A 서비스에 로그인 하면 브라우저에 A 서비스의 로그인 관련 쿠키 정보가 남게됩니다. 이후 동일 브라우저에서 악의적인 코드가 있는 B 서비스로 접속하게 되면 B 서비스의 페이지에서는 A 서비스로 임의의 권한이 필요한 Request를 전송할 수 있게 됩니다.

이런 문제를 해결하기 위해 A 서비스에서 Response 시 Token을 발행하여 그 다음 Request에 발행된 Token이 Header에 없는 경우 권한이 없는 요청을 인식할 수 있도록 합니다.

구글 검색 결과의 몇몇 문서에서는 http.csrf().disable()와 같이 csrf를 disable 하라고 하지만 이렇게 할 경우 보안에 문제가 발생할 수 있기 때문에 추천하지 않습니다. 그러면 csrf 가 enable 되어 있는 상태에서 403 Forbidden 에러가 발생하지 않게 하려면 어떻게 해야 할까요? 심플하게 Ajax 요청 Header에 csrf token 정보를 포함해서 전송하면 됩니다. 다음과 같이 HTML의 <head> 내에 csrf meta tag를 추가합니다.

<meta id="_csrf" name="_csrf" th:content="${_csrf.token}"/>
<!-- default header name is X-CSRF-TOKEN -->
<meta id="_csrf_header" name="_csrf_header" th:content="${_csrf.headerName}"/>

그리고 Ajax 호출 시 사용하는 xhr에 request header를 이 정보를 이용하도록 설정합니다.

var token = $("meta[name='_csrf']").attr("content");
var header = $("meta[name='_csrf_header']").attr("content");

$(function() {
    $(document).ajaxSend(function(e, xhr, options) {
        xhr.setRequestHeader(header, token);
    });
});

이렇게 하면 이후 전송되는 Ajax 호출의 header에 csrf token이 추가되어 전송되기 때문에 csrf  token으로 인한 403 에러는 발생하지 않습니다.

Read more

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

By 김형준