Introduction

Spring Security adds frame-protection headers because embedding your pages inside another site can enable clickjacking attacks. If you disable X-Frame-Options, do it deliberately and understand that the better question is often not "how do I remove it," but "what framing policy do I actually want."

Use the Modern Header Configuration API

In current Spring Security configuration, header behavior is usually configured through a SecurityFilterChain bean.

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3import org.springframework.security.config.annotation.web.builders.HttpSecurity;
4import org.springframework.security.web.SecurityFilterChain;
5
6@Configuration
7public class SecurityConfig {
8
9    @Bean
10    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
11        http
12            .headers(headers -> headers
13                .frameOptions(frameOptions -> frameOptions.disable())
14            );
15
16        return http.build();
17    }
18}

That configuration disables the X-Frame-Options header entirely.

Prefer Narrower Policies When Possible

Fully disabling the header is the broadest option and often not the safest one. If the real requirement is simply to allow framing from the same origin, use sameOrigin() instead.

1@Bean
2SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
3    http
4        .headers(headers -> headers
5            .frameOptions(frameOptions -> frameOptions.sameOrigin())
6        );
7
8    return http.build();
9}

This is a common choice for embedded tooling such as an H2 console or internal admin pages where same-origin framing is acceptable.

Understand Why the Header Exists

X-Frame-Options is a clickjacking defense. Without it, another site can try to display your page inside an invisible or disguised frame and trick users into clicking on actions they did not intend.

That is why disabling it should not be treated as a cosmetic change. It changes browser behavior in a way that can directly affect user safety.

If your application genuinely needs controlled embedding, a more complete modern strategy may involve a Content Security Policy with a frame-ancestors directive. That gives finer control than simply dropping the older header.

Scope the Change to the Real Need

Do not remove frame protection globally just because one route needs to be embeddable. If only a small part of the application requires different framing rules, consider isolating that part with a more targeted security configuration instead of weakening every response.

The practical engineering question is scope: how much of the application should be frameable, by whom, and under which conditions.

Test the Actual Response Headers

After changing the configuration, verify the result with browser developer tools, curl, or an HTTP client.

curl -I http://localhost:8080

This matters because header configuration can be influenced by multiple filters, reverse proxies, or environment-specific security layers. Looking at the actual response is faster than reasoning from configuration alone.

Also remember that upstream infrastructure can add or rewrite security headers. If a reverse proxy, API gateway, or platform security layer injects its own framing policy, changing Spring Security alone may not produce the final browser behavior you expect.

If the business requirement is third-party embedding, document exactly which embedding origins are allowed and why. Security headers are easiest to weaken and hardest to tighten later when the original framing requirement was never stated precisely.

Common Pitfalls

Disabling X-Frame-Options globally when only one endpoint needed a framing exception increases risk unnecessarily.

Assuming the change is harmless because an iframe use case exists ignores the clickjacking threat model.

Forgetting to verify the final response headers can leave you debugging the wrong layer of the stack.

Summary

• In modern Spring Security, disable the header through SecurityFilterChain header configuration.
• Prefer sameOrigin() or a more targeted policy when full disabling is not necessary.
• Treat frame-header changes as security decisions, not just browser-behavior tweaks.
• Verify the final HTTP response instead of trusting configuration by inspection alone.