Method-Level Security

Method-Level Security allows you to enforce authorization rules directly on individual methods (service or controller layer), instead of relying only on URL-based security.

👉 It answers the critical question:

“Who is allowed to execute this method?”

Even if an API endpoint is accessible, method-level security guarantees that only authorized users can execute the underlying business logic.

Why Method-Level Security?

URL-based security alone is often not sufficient.

Problems Without Method-Level Security

• Same endpoint, different business rules
• Different roles for different operations
• Internal service-to-service calls bypass controller security
• Shared services in microservices architecture
• Accidental exposure due to controller misconfiguration

Benefits

• Protects business logic, not just URLs
• Works even for internal method calls
• Enables fine-grained access control
• Essential for microservices & shared services
• Prevents security bypass at controller level

Enabling Method-Level Security

Spring Boot 3 / Spring Security 6+

@Configuration
@EnableMethodSecurity
publicclassSecurityConfig {
}

This enables:

• @PreAuthorize
• @PostAuthorize
• @Secured
• @RolesAllowed

Spring Boot 2.x (Legacy)

@EnableGlobalMethodSecurity(
    prePostEnabled = true,
    securedEnabled = true,
    jsr250Enabled = true
)

Common Method-Level Security Annotations

1. @PreAuthorize

• Executed before method invocation
• Method execution is blocked if the rule fails
• Supports SpEL (Spring Expression Language)

@PreAuthorize("hasRole('ADMIN')")
publicvoiddeleteUser(Long id) {
}

Why @PreAuthorize is Preferred

• Fine-grained access control
• Works with roles, authorities, scopes
• Supports JWT & OAuth2 claims
• Can validate method parameters
• Best choice for real-world systems

2. @PostAuthorize

• Executed after method execution
• Used when access depends on returned data

@PostAuthorize("returnObject.owner == authentication.name")
public DocumentgetDocument(Long id) {
return documentService.findById(id);
}

Users can access only their own data, even if they guess another ID.

3. @Secured

• Simple role-based authorization
• No SpEL support

@Secured("ROLE_ADMIN")
publicvoidcreateUser() {
}

Limitations:

• Role-only checks
• Requires ROLE_ prefix
• Less flexible than @PreAuthorize

4. @RolesAllowed (JSR-250)

@RolesAllowed("ADMIN")
publicvoidupdateUser() {
}

Requires:

@EnableMethodSecurity(jsr250Enabled = true)

Mostly used for standards-based or legacy systems.

@PreAuthorize with SpEL (Spring Expression Language)

Spring Security supports SpEL (Spring Expression Language) in the @PreAuthorize annotation to define fine-grained authorization rules at the method level.

@PreAuthorize expressions are evaluated before method execution using data from the SecurityContext, method parameters, and custom beans.

Common Security Expressions

Practical Example – Ownership Check

@PreAuthorize("#userId == authentication.principal.id")
public UsergetUserProfile(Long userId) {
return userService.findById(userId);
}

What this does

• Compares the requested userId with the logged-in user’s ID
• Prevents users from accessing other users’ data
• Enforces data ownership at the business-logic level

Even if the API endpoint is accessible, the method will not execute unless the condition is satisfied.

Ownership + Admin Access (Real-World Pattern)

@PreAuthorize("#userId == authentication.principal.id or hasRole('ADMIN')")
public UsergetUser(Long userId) {
return userService.findById(userId);
}

• Users can access their own data
• Admins can access all data

Very common in banking, SaaS, admin dashboards

Method-Level Security with JWT

When using JWT-based authentication:

• Roles and scopes are extracted in the JWT filter
• Converted to Spring Security authorities
• Stored inside:

SecurityContextHolder.getContext().getAuthentication()

Example – Admin Only API

@PreAuthorize("hasRole('ADMIN')")
@GetMapping("/admin/reports")
public List<Report>getReports() {
return reportService.findAll();
}

Authorization Flow

JWT
 ↓
Authorities extracted
 ↓
SecurityContext
 ↓
@PreAuthorizecheck
 ↓
Method execution

Method-Level Security with OAuth2 / OIDC

In OAuth2 / OIDC:

• Scopes are mapped as Spring Security authorities
• Prefix used: SCOPE_

Scope-Based Access Control

@PreAuthorize("hasAuthority('SCOPE_admin')")
@GetMapping("/api/admin")
public StringadminApi() {
return"Admin API";
}

Common OAuth2 Authorities

• SCOPE_read
• SCOPE_write
• SCOPE_admin

Used heavily in API security & resource servers

Custom Authorization Logic

For complex business rules, use a custom authorization bean.

Method Security

@PreAuthorize("@orderSecurity.isOwner(#orderId)")
public OrderviewOrder(Long orderId) {
return orderService.find(orderId);
}

Custom Security Bean

@Component
publicclassOrderSecurity {

publicbooleanisOwner(Long orderId) {
// custom ownership or tenant logic
returntrue;
    }
}

Custom Permission Evaluator (Enterprise-Level)

Used for domain-object security (ACLs, multi-tenant apps).

@PreAuthorize("hasPermission(#doc, 'WRITE')")
publicvoideditDocument(Document doc) {
}

• Object-level permissions
• Fine-grained access control
• Common in document systems, SaaS platforms

Role Hierarchy (Advanced Authorization)

Allows higher roles to inherit permissions of lower roles.

Requirement

ADMIN should have all USER permissions

Configuration

@Bean
RoleHierarchyroleHierarchy() {
RoleHierarchyImplhierarchy=newRoleHierarchyImpl();
    hierarchy.setHierarchy("""
        ROLE_ADMIN > ROLE_MANAGER
        ROLE_MANAGER > ROLE_USER
    """);
return hierarchy;
}

Result

• Avoids permission duplication
• Cleaner @PreAuthorize rules
• Easy to maintain

Execution Flow (Internal Working)

MethodCall
   ↓
Spring AOP Proxy
   ↓
Security Expression Evaluation
   ↓
Access Granted / Denied
   ↓
Method Executes

Method-Level vs URL-Level Security

Common Mistakes

• Forgetting @EnableMethodSecurity
• Using @Secured for complex logic
• Incorrect JWT role / scope mapping
• Mixing ROLE_ and non-ROLE authorities
• Securing only controllers, not services

Best Practices

• Prefer @PreAuthorize
• Secure service layer, not just controllers
• Keep rules simple & readable
• Combine with JWT / OAuth2 / OIDC
• Use role hierarchy to avoid duplication
• Keep authorization close to business logic

Where Method-Level Security Is Used

Method-Level Security protects business logic, not just endpoints, ensuring only authorized users can execute methods.

1. Banking Systems – Secure fund transfers, account changes; roles like ROLE_TELLER or ROLE_ADMIN control access.
2. Admin Dashboards – Fine-grained control; only ROLE_SUPER_ADMIN can modify sensitive settings.
3. Multi-Tenant Apps – Restrict actions to a tenant’s users (@PreAuthorize("#tenantId == authentication.principal.tenantId")).
4. SaaS Platforms – Role-based access with complex permissions; supports custom evaluators for dynamic rules.
5. Enterprise Microservices – Secure internal APIs; integrate with JWT, OAuth2, or OIDC scopes.

Key Takeaways

• Method-Level Security protects business logic
• @PreAuthorize is the most powerful annotation
• Works seamlessly with JWT, OAuth2, OIDC
• Prevents internal security bypass
• Essential for real-world Spring Security

Conclusion

Method-Level Security is a crucial layer of protection in Spring applications. By securing methods directly, it ensures that only authorized users can execute business logic, even if endpoints are publicly accessible or internally invoked. Combined with JWT, OAuth2, or OIDC, it enables fine-grained, robust, and maintainable access control across microservices, SaaS platforms, banking systems, and enterprise applications.

In short: URL security protects access points, method-level security protects the logic itself.