@Secured annotation in Spring Boot - Step-by-Step Execution

Concept Flow - @Secured annotation

Method call

↓

Check @Secured roles

↓

User roles match?

No→Access Denied

Yes↓

Execute method

↓

Return result

When a method with @Secured is called, Spring checks if the user has the required role(s). If yes, the method runs; if not, access is denied.

Execution Sample

Spring Boot

@Secured("ROLE_ADMIN")
public void adminTask() {
  // admin-only logic
}

This method runs only if the user has the ROLE_ADMIN authority.

Execution Table

Step	Action	User Roles	Required Roles	Access Decision	Method Execution
1	Call adminTask()	[ROLE_USER]	[ROLE_ADMIN]	Denied	No
2	Call adminTask()	[ROLE_ADMIN]	[ROLE_ADMIN]	Allowed	Yes

💡 Access denied when user roles do not include required ROLE_ADMIN

Variable Tracker

Variable	Start	After Step 1	After Step 2
User Roles	[ROLE_USER]	[ROLE_USER]	[ROLE_ADMIN]
Access Decision	N/A	Denied	Allowed
Method Execution	N/A	No	Yes

Key Moments - 2 Insights

Why does the method not run when the user has ROLE_USER but not ROLE_ADMIN?

Because @Secured requires the user to have ROLE_ADMIN. The execution_table row 1 shows access is denied when roles don't match.

Can the method run if the user has multiple roles including ROLE_ADMIN?

Yes, as long as ROLE_ADMIN is present, access is allowed. The check looks for required roles, not exclusive roles.

Visual Quiz - 3 Questions

Look at the execution_table, what is the Access Decision at Step 1?

A Allowed

B Denied

C Pending

D Error

💡 Hint

Check the Access Decision column for Step 1 in the execution_table.

At which step does the method actually execute?

A Step 1

B Both steps

C Step 2

D Neither step

💡 Hint

Look at the Method Execution column in the execution_table.

If the user roles changed to [ROLE_ADMIN, ROLE_USER], what would happen at Step 1?

A Access Allowed

B Access Denied

C Error due to multiple roles

D Method skipped

💡 Hint

The key_moments explain that having ROLE_ADMIN among roles allows access.

Concept Snapshot

@Secured annotation restricts method access by roles.
Place @Secured("ROLE_NAME") above methods.
Spring checks if user has required role before running method.
If user lacks role, access is denied and method is not executed.
Supports multiple roles; user must have at least one required role.

Full Transcript

The @Secured annotation in Spring Boot is used to protect methods by specifying required user roles. When a method annotated with @Secured is called, Spring checks the current user's roles. If the user has the required role, the method runs normally. If not, access is denied and the method does not execute. For example, a method annotated with @Secured("ROLE_ADMIN") will only run if the user has the ROLE_ADMIN authority. The execution table shows two calls: one with a user having ROLE_USER only, which is denied, and one with ROLE_ADMIN, which is allowed. This helps secure sensitive parts of an application by role-based access control.

Practice

1.

What is the main purpose of the @Secured annotation in Spring Boot?

easy

A. To restrict access to methods based on user roles

B. To define database entity relationships

C. To configure application properties

D. To handle HTTP request mappings

Solution

1. Step 1: Understand the role of @Secured

   The @Secured annotation is used to limit method access to users with specific roles.

2. Step 2: Compare with other options

   Other options relate to different Spring features like database or HTTP handling, not security roles.

3. Final Answer:

   To restrict access to methods based on user roles -> Option A

4. Quick Check:

   @Secured controls method access by roles [OK]

Hint: Remember: @Secured controls who can run a method [OK]

Common Mistakes:

• Confusing @Secured with @RequestMapping
• Thinking @Secured configures database
• Assuming @Secured manages app properties

2.

Which of the following is the correct way to use @Secured to allow only users with role ADMIN to access a method?

@Secured({"?"})
public void adminMethod() { }

easy

A. ROLE_ADMIN

B. ADMIN

C. ROLE-ADMIN

D. ROLE_ADMINISTRATOR

Solution

1. Step 1: Recall role naming convention

   Spring Security requires roles to be prefixed with ROLE_, so ROLE_ADMIN is correct.

2. Step 2: Check other options

   ADMIN without prefix is invalid; ROLE-ADMIN uses wrong separator; ROLE_ADMINISTRATOR is a different role.

3. Final Answer:

   ROLE_ADMIN -> Option A

4. Quick Check:

   Roles need ROLE_ prefix [OK]

Hint: Always prefix roles with ROLE_ inside @Secured [OK]

Common Mistakes:

• Omitting ROLE_ prefix
• Using dash (-) instead of underscore (_)
• Using wrong role names

3.

Given this method secured with @Secured({"ROLE_USER", "ROLE_ADMIN"}), what happens if a user with role ROLE_GUEST calls it?

@Secured({"ROLE_USER", "ROLE_ADMIN"})
public String getData() {
    return "Secret Data";
}

medium

A. The method executes and returns "Secret Data"

B. The method executes but returns empty string

C. The method returns null

D. Access denied error is thrown

Solution

1. Step 1: Understand role checking with @Secured

   The annotation allows only users with roles ROLE_USER or ROLE_ADMIN.

2. Step 2: Check user role

   User has ROLE_GUEST, which is not allowed, so access is denied.

3. Final Answer:

   Access denied error is thrown -> Option D

4. Quick Check:

   User role mismatch causes denial [OK]

Hint: Only listed roles can access; others get denied [OK]

Common Mistakes:

• Assuming method runs for any role
• Thinking method returns null on denial
• Confusing role names

4.

Identify the error in this usage of @Secured:

@Secured("ROLE_ADMIN")
public void adminTask() { }

medium

A. Role name should not have ROLE_ prefix

B. Missing curly braces around roles array

C. Method must return a value

D. Annotation should be @RolesAllowed instead

Solution

1. Step 1: Check @Secured syntax

   @Secured expects an array of roles, so roles must be inside curly braces {}.

2. Step 2: Analyze given code

   Here, roles are given as a single string without braces, causing syntax error.

3. Final Answer:

   Missing curly braces around roles array -> Option B

4. Quick Check:

   @Secured requires roles in braces [OK]

Hint: Always use braces {} for roles in @Secured [OK]

Common Mistakes:

• Omitting braces for single role
• Removing ROLE_ prefix
• Confusing @Secured with @RolesAllowed

5.

You want to secure two methods: one accessible only by ROLE_ADMIN, and another accessible by either ROLE_USER or ROLE_MANAGER. Which is the correct way to annotate these methods?

Method 1:
@Secured({"?"})
public void adminOnly() { }

Method 2:
@Secured({"?"})
public void userOrManager() { }

hard

A. {"ROLE_ADMIN"} and {"ROLE_USER|ROLE_MANAGER"}

B. {"ADMIN"} and {"USER", "MANAGER"}

C. {"ROLE_ADMIN"} and {"ROLE_USER", "ROLE_MANAGER"}

D. {"ROLE_ADMIN", "ROLE_USER"} and {"ROLE_MANAGER"}

Solution

1. Step 1: Secure Method 1 for ROLE_ADMIN only

   Use @Secured({"ROLE_ADMIN"}) to restrict access to admins.

2. Step 2: Secure Method 2 for ROLE_USER or ROLE_MANAGER

   Use @Secured({"ROLE_USER", "ROLE_MANAGER"}) to allow either role.

3. Final Answer:

   {"ROLE_ADMIN"} and {"ROLE_USER", "ROLE_MANAGER"} -> Option C

4. Quick Check:

   Use arrays with ROLE_ prefix for multiple roles [OK]

Hint: Use arrays with ROLE_ prefix for each method [OK]

Common Mistakes:

• Omitting ROLE_ prefix
• Using pipe '|' inside role strings
• Mixing roles in one annotation incorrectly