Fix the WASA Issue : IDOR Vulnerability

[vanitha1822]

📋 Description

JIRA ID:

AMM-1922
Extract the userId from the JWT token instead of getting it from payload, to prevent this IDOR Vulnerability.

---

✅ Type of Change

• 🛠 Refactor (change that is neither a fix nor a new feature)

---

Summary by CodeRabbit

• New Features

  • Added JWT-based authorization to multiple endpoints for enhanced security and user access control.

• Dependencies

  • Updated core API dependency to version 3.6.1.
  • Integrated SLF4J logging framework for improved log management.
  • Adjusted logging configuration for better system compatibility.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

A systematic addition of JWT-based authorization to multiple Spring controller endpoints. UserId is extracted from JWT tokens in cookies and validated against provided userIDs in path variables or request payloads. Unauthorized requests return error responses. Also includes tm-api version upgrade to 3.6.1 and addition of slf4j logging dependencies.

Changes

Cohort / File(s)	Summary
Dependency Management pom.xml	Version bump: tm-api from 3.4.0 to 3.6.1; added org.slf4j:slf4j-api and org.slf4j:slf4j-simple dependencies; commented out spring-boot-starter-logging exclusion.
JWT Utility Enhancement src/main/java/com/iemr/tm/utils/JwtUtil.java	Added public method getUserIdFromToken(String token) to extract userId claim from JWT token.
Controller Authorization Checks src/main/java/com/iemr/tm/controller/common/main/WorklistController.java, src/main/java/com/iemr/tm/controller/login/IemrMmuLoginController.java, src/main/java/com/iemr/tm/controller/teleconsultation/TeleConsultationController.java, src/main/java/com/iemr/tm/controller/videoconsultationcontroller/VideoConsultationController.java	Added JWT-based authorization to endpoints by: autowiring JwtUtil, accepting HttpServletRequest parameters, extracting userId from JWT cookies, comparing token userId against path variable or request payload userID, and returning "Unauthorized access!" error (code 5000 or 5001) on mismatch.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Controller
    participant JwtUtil
    participant CookieUtil
    participant Service

    Client->>Controller: HTTP Request (with Cookie containing JWT)
    Controller->>CookieUtil: Extract JWT from Cookie
    CookieUtil-->>Controller: JWT Token
    Controller->>JwtUtil: getUserIdFromToken(token)
    JwtUtil-->>Controller: userId from Token
    
    alt userId matches path/payload userID
        Controller->>Service: Call Business Logic
        Service-->>Controller: Result
        Controller-->>Client: 200 OK with Data
    else userId mismatch
        Controller-->>Client: 5000/5001 Error - "Unauthorized access!"
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Security-sensitive changes: JWT validation and authorization logic require careful review for correctness and consistency across endpoints.
• Repetitive patterns: Same authorization pattern applied across four different controllers may contain subtle differences requiring individual verification.
• Method signature changes: Multiple endpoints add HttpServletRequest parameter; ensure all call sites are compatible.
• Error handling consistency: Verify that error codes (5000 vs 5001) and messages are used consistently and appropriately across controllers.

Possibly related PRs

• 401 unauthorized issue resolved #64: Introduces cookie-based JWT handling with JwtUtil and CookieUtil in service classes for token forwarding, complementing this PR's controller-level authorization checks.

Poem

🐰 A rabbit hops through tokens bright,
JWT claims now held tight,
Cookie-crumbs to userIds lead,
Authorization checks indeed!
No trespassing past the gates of auth, 🔐
Safe travels for the rightful path!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title 'Fix the WASA Issue : IDOR Vulnerability' accurately reflects the main objective of implementing JWT-based authorization checks across multiple controllers to prevent IDOR (Insecure Direct Object Reference) vulnerabilities by validating that request userIDs match JWT token userIDs.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[drtechie]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[drtechie]

Are you sure about adding these.
I think these were removed once for ELK integration if I remember

[vanitha1822]

I enabled this to get the console outputs. If it's meant for ELK integration, I'll remove it

[coderabbitai]

Actionable comments posted: 6

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/main/java/com/iemr/tm/controller/login/IemrMmuLoginController.java (1)

96-111: Add JWT validation to remaining unprotected endpoints.

The PR fixes IDOR vulnerabilities in getUserServicePointVanDetails and getUserVanSpDetails by extracting the JWT token and comparing the requested userID with the token's user ID. However, two endpoints remain unprotected and vulnerable to IDOR:

1. getServicepointVillages (line 96) - accepts servicePointID without JWT validation
2. getUserSpokeDetails (line 149) - accepts psmId without JWT validation

Both endpoints bypass the Authorization requirement and directly process user-supplied parameters without verifying the requesting user has access to that resource. Add JWT validation consistent with the protected endpoints to prevent unauthorized access.

🧹 Nitpick comments (1)

pom.xml (1)

9-9: Reconsider adding slf4j-simple alongside Spring Boot’s default logging and verify version alignment.

With the commented‑out exclusion, spring-boot-starter/spring-boot-starter-web will again pull in spring-boot-starter-logging, which already provides slf4j-api plus a logback binding. Adding:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>${slf4j.version}</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>${slf4j.version}</version>
</dependency>

means you may have multiple SLF4J bindings (logback + slf4j‑simple) on the classpath, which typically produces warnings and can lead to confusing logging behavior. Also, you’re explicitly pinning the SLF4J version rather than relying on Spring Boot’s dependency management.

I’d suggest either:

• Relying solely on Spring Boot’s spring-boot-starter-logging (remove slf4j-simple, and likely the explicit slf4j-api), or
• Explicitly excluding logback and using only slf4j-simple if that’s deliberate, but then ensuring all other logging expectations still hold.

Please also confirm that ${slf4j.version} resolves to the version you expect under the spring-boot-starter-parent BOM and doesn’t conflict with Boot’s managed stack.

Also applies to: 60-68, 131-140

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dc84bd9 and b23f4c7.

📒 Files selected for processing (6)

• pom.xml (3 hunks)
• src/main/java/com/iemr/tm/controller/common/main/WorklistController.java (5 hunks)
• src/main/java/com/iemr/tm/controller/login/IemrMmuLoginController.java (4 hunks)
• src/main/java/com/iemr/tm/controller/teleconsultation/TeleConsultationController.java (3 hunks)
• src/main/java/com/iemr/tm/controller/videoconsultationcontroller/VideoConsultationController.java (2 hunks)
• src/main/java/com/iemr/tm/utils/JwtUtil.java (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-10-01T20:25:37.804Z

Learnt from: abhijeetw035
Repo: PSMRI/TM-API PR: 95
File: package.json:15-23
Timestamp: 2025-10-01T20:25:37.804Z
Learning: In the TM-API repository (Java Spring Boot project), the lint-staged configuration uses echo statements as intentional placeholders rather than actual linting commands. This design decision prioritizes reliability and low setup friction for contributors, focusing on commit message linting (the primary goal) while avoiding complex toolchain dependencies for code linting. The infrastructure is ready for future enhancement if code linting becomes a requirement.

Applied to files:

• pom.xml

🔇 Additional comments (1)

src/main/java/com/iemr/tm/controller/login/IemrMmuLoginController.java (1)

38-39: LGTM! JWT utilities correctly imported and injected.

The necessary utilities for JWT-based authorization are properly imported and the JwtUtil dependency is correctly autowired.

Also applies to: 44-44, 56-57

[drtechie]

Do we need to still accept userID from client side?
Instead of matching, get the userID directly from JWT?

[vanitha1822]

Instead of change the FE flow, just accept the userID from client side and compare it with JWT UserId to authorize the user.

[drtechie]

Mostly same comments as the other PR.

[sonarqubecloud]

Quality Gate failed

Failed conditions
13.6% Duplication on New Code (required ≤ 3%)
B Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE