@Secured annotation in Spring Boot - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a method annotated with @Secured is accessed by an unauthorized user?

Consider a Spring Boot method annotated with @Secured("ROLE_ADMIN"). What is the expected behavior if a user without the ROLE_ADMIN role tries to access this method?

Spring Boot

import org.springframework.security.access.annotation.Secured;

public class AdminService {
    @Secured("ROLE_ADMIN")
    public String getAdminData() {
        return "Sensitive Admin Data";
    }
}

A Spring Security throws an AccessDeniedException preventing method execution.

B The method executes normally and returns the data regardless of user role.

C The method returns null without throwing any exception.

D The application crashes with a NullPointerException.

💡 Hint

Think about how Spring Security enforces role-based access control.

The @Secured annotation restricts method access to users with specified roles. If a user lacks the required role, Spring Security throws an AccessDeniedException to prevent unauthorized access.

📝 Syntax

intermediate

Which of the following is the correct way to use @Secured for multiple roles?

Choose the correct syntax to allow access to a method for users with either ROLE_USER or ROLE_ADMIN using @Secured.

A @Secured("ROLE_USER" || "ROLE_ADMIN")

B @Secured("ROLE_USER, ROLE_ADMIN")

C @Secured({"ROLE_USER", "ROLE_ADMIN"})

D @Secured(["ROLE_USER", "ROLE_ADMIN"])

💡 Hint

Remember that @Secured accepts an array of strings.

The @Secured annotation expects an array of role names as strings. The correct syntax uses curly braces to define the array: @Secured({"ROLE_USER", "ROLE_ADMIN"}).

🔧 Debug

advanced

Why does @Secured annotation not restrict access as expected?

A developer added @Secured("ROLE_ADMIN") to a method, but users without ROLE_ADMIN can still access it. What is the most likely cause?

Spring Boot

import org.springframework.security.access.annotation.Secured;

public class ReportService {
    @Secured("ROLE_ADMIN")
    public String generateReport() {
        return "Report Data";
    }
}

A The method is private, so <code>@Secured</code> does not apply.

B The <code>@EnableGlobalMethodSecurity(securedEnabled = true)</code> annotation is missing in the configuration.

C The user roles are case-sensitive and should be lowercase.

D The <code>@Secured</code> annotation requires a <code>@Transactional</code> annotation to work.

💡 Hint

Check if method security is enabled in the Spring Security configuration.

For @Secured annotations to work, method security must be enabled by adding @EnableGlobalMethodSecurity(securedEnabled = true) in the configuration class. Without this, the annotations are ignored.

❓ state_output

advanced

What is the output when a user with ROLE_USER calls a method annotated with @Secured({"ROLE_USER", "ROLE_ADMIN"})?

Given the method below, what will be the output if a user with only ROLE_USER calls it?

Spring Boot

import org.springframework.security.access.annotation.Secured;

public class DataService {
    @Secured({"ROLE_USER", "ROLE_ADMIN"})
    public String fetchData() {
        return "Data fetched successfully";
    }
}

A "Data fetched successfully"

B NullPointerException is thrown

C AccessDeniedException is thrown

D "Access denied" string is returned

💡 Hint

Check if the user's role matches any role in the annotation.

The @Secured annotation allows access if the user has any one of the specified roles. Since the user has ROLE_USER, the method executes and returns the string.

🧠 Conceptual

expert

Why might you choose @PreAuthorize over @Secured in Spring Security?

Both @Secured and @PreAuthorize annotations can restrict method access. What is a key advantage of using @PreAuthorize?

A <code>@PreAuthorize</code> automatically logs access attempts.

B <code>@PreAuthorize</code> is faster at runtime than <code>@Secured</code>.

C <code>@PreAuthorize</code> does not require enabling method security in configuration.

D <code>@PreAuthorize</code> supports complex SpEL expressions for fine-grained access control.

💡 Hint

Think about flexibility in defining access rules.

@PreAuthorize allows using Spring Expression Language (SpEL) to write complex access rules, such as checking method parameters or combining roles with logical operators, which @Secured cannot do.

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