정적 자원 관리

• 스프링 시큐리티에서 RequestMatcher 인스턴스를 등록하여 무시해야 할 요청을 지정 가능
• 주로 정적 자원(이미지, CSS, JavaScript 파일 등)에 대한 요청이나 특정 엔드포인트가 보안 필터를 거치지 않도록 설정할 때 사용

사용 방법

@Bean
public WebSecurityCustomizer webSecurityCustomizer() {
	 return (webSecurity) -> {
		 webSecurity.ignoring().requestMatchers(PathRequest.toStaticResources().atCommonLocations());
	 };
 }

 

StaticResourceLocation

CSS("/css/**"),
JAVA_SCRIPT("/js/**"),
IMAGES("/images/**"),
WEB_JARS("/webjars/**"),
FAVICON("/favicon.*", "/*/icon-*");

---

Ignoring보다 permitAll 권장

http.authorizeHttpRequests(auth -> auth
 .requestMatchers("/css/**", "/images/**", "/js/**", "/webjars/**", "/favicon.*", "/*/icon-*").permitAll()
 .requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll()
 .anyRequest().authenticated());

• 이전에는 모든 요청마다 세션을 확인해야 해서 성능 저하가 있었지만 스프링 시큐리티 6 부터는 권한 부여 규칙에서 필요한 경우를 제외하고는 세션을 확인하지 않음
• 성능 문제가 해결되었기 때문에 모든 요청에 대해서 permitAll을 사용할 것을 권장, 정적 자원에 대한 요청일지라도 안전한 헤더를 작성할 수 있어 더 안전

---

정리

• Ignoring을 하게 되면 아예 스프링 시큐리티 필터 체인을 거치지 않게 되어 XSS 같은 공격에 취약하다고 함
• 이전 버전에서는 permitAll을 하더라도 항상 세션에서 SpringContext를 꺼내고 그 안에 인증 객체를 꺼내는 작업들로 인해 오버헤드가 발생하였음
• 하지만, 스프링 시큐리티 6이후 버전에서는 그런 부분을 개선이 되어 오버헤드가 거의 발생하지 않게 되었고, permitAll을 사용하게 되면 요청이 스프링 시큐리티 필터 체인을 통과하여 보안 관련 헤더가 적용되고, 필요할 경우 추가적인 보안 로직을 실행