1|Page

CY-4001

Secure Software design

Assignment 3

API SECURITY
2|Page

Table of Contents
GitHub Repository ........................................................................................................................................ 4
Link of repository: .................................................................................................................................... 4
Branches of all fixes: ................................................................................................................................ 4
Pull Requests:............................................................................................................................................ 5
Security Fix #1 — Secure Password Storage with BCrypt (API2:2023 – Broken Authentication) ............. 6
Overview ................................................................................................................................................... 6
Vulnerability ............................................................................................................................................. 6
Fix Implemented ....................................................................................................................................... 6
Testing Performed ..................................................................................................................................... 7
Security Fix #2 — Enforcing Authentication and Role-Based Access (API5:2023 – Broken Function
Level Authorization) ..................................................................................................................................... 8
Overview ................................................................................................................................................... 8
Vulnerability ............................................................................................................................................. 8
Fix Implemented ....................................................................................................................................... 9
Testing Performed ..................................................................................................................................... 9
Security Fix #3 — Ownership Enforcement in Controllers (API1:2023 – Broken Object Level
Authorization) ............................................................................................................................................. 10
Overview ................................................................................................................................................. 10
Vulnerability ........................................................................................................................................... 11
Fix Implemented ..................................................................................................................................... 11
Testing Performed ................................................................................................................................... 11
Security Fix #4 — Data Exposure Prevention via DTOs (API3:2023 – Broken Object Property Level
Authorization) ............................................................................................................................................. 12
Overview ................................................................................................................................................. 13
Vulnerability ........................................................................................................................................... 13
Fix Implemented ..................................................................................................................................... 13
Testing Performed ................................................................................................................................... 14
Security Fix #5: Rate Limiting Implementation (API4:2023 – Unrestricted Resource Consumption) ...... 15
Overview ................................................................................................................................................. 15
Vulnerability ........................................................................................................................................... 15
Fix Implemented ..................................................................................................................................... 16
Testing Performed ................................................................................................................................... 16
3|Page

Security Fix #6 — Mass Assignment Protection (API6:2023 – Unrestricted Access to Sensitive Business
Flows) ......................................................................................................................................................... 17
Overview ................................................................................................................................................. 17
Vulnerability ........................................................................................................................................... 18
Fix Implemented ..................................................................................................................................... 18
Testing Performed ................................................................................................................................... 18
Security Fix #7 — JWT Hardening and Token Validation (API2:2023 – Broken Authentication) ........... 19
Overview ................................................................................................................................................. 19
Vulnerability ........................................................................................................................................... 20
Fix Implemented ..................................................................................................................................... 20
Testing Performed ................................................................................................................................... 20
Security Fix #8 — Error Handling and Information Leakage Mitigation (API7:2023 – Server-Side
Request Forgery / Information Exposure) .................................................................................................. 23
Overview: ................................................................................................................................................ 23
Vulnerability ........................................................................................................................................... 23
Fix Implemented ..................................................................................................................................... 23
Testing Performed .................................................................................................................................. 24
Security Fix #9 — Input Validation and Business Logic Enforcement (API8:2023 – Security
Misconfiguration / Injection) ...................................................................................................................... 25
Overview ................................................................................................................................................. 25
Vulnerability ........................................................................................................................................... 25
Fix Implemented ..................................................................................................................................... 26
Files Modified: ........................................................................................................................................ 26
Testing Performed ................................................................................................................................... 26
Security Fix #10 — Integration Testing for Security Verification (Cross-cutting Control) ....................... 27
Overview ................................................................................................................................................. 27
Vulnerability ........................................................................................................................................... 27
Fix Implemented ..................................................................................................................................... 27
Testing Performed ................................................................................................................................... 29
4|Page

GitHub Repository
Link of repository:
[Link]

Branches of all fixes:

5|Page

Pull Requests:
6|Page

Security Fix #1 — Secure Password Storage with BCrypt (API2:2023 –

Broken Authentication)
Overview
The system had previously stored user passwords in plaintext and authenticated them with direct
string comparison, where an explicit authentication vulnerability existed. The patch added BCrypt
hashing to securely hash all passwords prior to storage and performs safe verification during login.
This patch ensures compliance with OWASP API2:2023, CWE-256, and NIST SP 800-63B,
greatly improving authentication resilience against database compromise, brute-force, and
credential reuse attacks.

Vulnerability
● Passwords were stored directly in plaintext in the APP_USER table.
● Login verification was based on equals() comparison, which was susceptible to credential
theft and timing attacks.
● Upon database compromise, all the user credentials (e.g., "alice123") would be
completely disclosed.
● Violated security standards and best practices for password security (OWASP, PCI-DSS,
GDPR).

Fix Implemented
● Integrated BCryptPasswordEncoder with 10 rounds for adaptive salted hashing of
passwords.
● Refactored AuthController to use [Link]() in place of plaintext
equals() comparison for secure verification.
● Added /api/register endpoint to process new user registrations with input validation and
hashing prior to storage.
● Refactored [Link] such that all seeded users (i.e., Alice and Bob) are saved with
hashed passwords.
● Increased JWT secret key in [Link] to achieve 256-bit requirement.
● Verified that original authentication flow is still functional and backward-compatible.
7|Page

Testing Performed
Test Case Action / Scenario Expected Result Actual Result Status
User Register new user Password stored as Verified in H2 DB — Passed
Registration via /api/register BCrypt hash hashed correctly
($2a$10$ format)
Login Success Login with correct Valid JWT token Token received Passed
credentials generated successfully
Login Failure Attempt login with 401 Unauthorized Unauthorized Passed
wrong password returned response confirmed
Database Inspect Passwords should be alice, bob both stored Passed
Verification APP_USER table hashed ($2a$10$) as BCrypt hashes
(H2 Console)
Automated Run PowerShell FIX 1 WORKING Output: FIX 1 Passed
Script Check verification script output expected WORKING – BCrypt
password stored and
login successful.
Overall Cross-check All authentication All checks successful, Passed
Validation functionality & flows secure and no plaintext
security compliant passwords found
8|Page

Security Fix #2 — Enforcing Authentication and Role-Based Access

(API5:2023 – Broken Function Level Authorization)
Overview
Prior to this solution, the Spring Security configuration provided uncontrolled access to vulnerable
API routes because overly liberal GET matchers and improper rule ordering granted unauthorized
access. Consequently, even non-authenticated users had access to protected information. The new
Security Filter Chain strictly authenticates all /api/** endpoints and limits /api/admin/** endpoints
to users with the ADMIN role.

Vulnerability
● OWASP API1, API5, API7 (2023): Unauthenticated users had access to /api/**
endpoints, including admin endpoints.
● CWE-285 / CWE-284: Insufficient or absent authorization controls across multiple
levels.
9|Page

● Root Cause: Filter chain misconfiguration — admin matcher following a lenient GET
rule, rendering it useless.
● Effect: Data access for unauthorized users, privilege escalation, and leakage of sensitive
user data.

Fix Implemented
● Updated [Link] to authenticate using JWT and role-based access control.
● Eliminated the insecure rule that permitted all GET requests to /api/ without auth.
● Secured admin routes are verified prior to general API routes for correct access control.
● Left /api/auth/** and /h2-console/** accessible to the public, but authenticated all other
/api/** endpoints.
● Included an ADMIN-only restriction for /api/admin/** routes.
● Enforced stateless session and JWT filter configuration for secure token management.

Testing Performed
Test Case Action / Scenario Expected Result Actual Result Status
Unauthorized Access 401/403 Forbidden Exception raised Passed
Admin Access /api/admin/users confirming block
without token
Authorized Access /api/users 200 OK Successful response Passed
User Access with valid JWT
Normal user 403 Forbidden Access denied Passed
User Role (Alice) →
Restriction /api/admin/metrics

Admin Role Admin (Bob) → Authorized access Passed

Access /api/admin/metrics 200 successful
OK
10 | P a g e

Automated PowerShell FIX #2 WORKING Output confirmed Passed

Script Output verification for - Unauthorized
unauthorized access blocked.
access

Unauthorized access is now fully blocked, role-based restrictions enforced, and the Spring Security
filter chain correctly prioritizes matchers while maintaining JWT-based stateless authentication.

Security Fix #3 — Ownership Enforcement in Controllers (API1:2023 –

Broken Object Level Authorization)

Overview
In order to mitigate Broken Object Level Authorization (BOLA) vulnerabilities by guaranteeing
that users can only access resources they own, ownership-based authorization restrictions were
implemented across account and user endpoints.
11 | P a g e

Vulnerability
Due to the application's prior lack of ownership verification on API endpoints, any authenticated
user could view or change the sensitive information of other users, including accounts, funds,
and profiles.
Due to missing checks that link resource access to the identity of the authenticated user, this
breached OWASP API1:2023 (Broken Object Level Authorization), exposing personal and
financial information.

Fix Implemented
Code Changes:

● [Link]

o Added ownership verification before accessing or modifying account data.

o Updated balance() and transfer() methods to ensure only account owners can view
balances or initiate transfers.

o For clarity and accuracy, explicit @PathVariable ("id") bindings and

authentication checks were added.

● [Link]

o Added permission logic so that, unless they have admin capabilities, users can
only read their own profiles.

o Restricted list() (user listing) and delete() actions to admin users only.

o The isAdmin() helper function was introduced to verify Spring Security authority
and user roles.

Testing Performed
Test Case Description Result
12 | P a g e

1. Own Verified that authenticated users can access Passed.

Resource only their own account balance and related Access granted with 200
Access data. OK
2. BOLA Verified that users cannot access or modify Passed.
Prevention resources belonging to other users. Access denied with 403
Forbidden
3. Admin Verified that administrator accounts can Passed.
Access access all user profiles and perform authorized Access granted with 200
actions. OK
4. User Listing Verified that user listing and administrative Passed.
Restriction functions are restricted to admin roles only. Access denied for non-
admins with 403
Forbidden

Every test scenario was successfully completed, demonstrating that attempts at unauthorized
access are appropriately prevented and that authorized user and administrator access is still
operational.

Security Fix #4 — Data Exposure Prevention via DTOs (API3:2023 –

Broken Object Property Level Authorization)
13 | P a g e

Overview
Implemented the Data Transfer Object (DTO) pattern to ensure that only necessary and non-
sensitive fields are provided in API responses, hence preventing excessive data exposure.

Vulnerability
Inadvertently disclosing private data like password hashes, admin privilege flags, and internal
database identifiers, the API endpoints were directly returning internal entity objects in JSON
answers.
Because it gave attackers access to private system information that would enable privilege
escalation, credential attacks, or data breaches, this violated OWASP API3:2023, Excessive
Data Exposure.

Fix Implemented
The data exposed through API answers was controlled and isolated using the DTO (Data
Transfer Object) paradigm.
Important actions included:

● To specify specified, sanitized output structures, distinct DTO classes (UserResponseDto

and AccountResponseDto) were created.
● Putting in place a centralized DtoMapper component to manage the conversion of entity
objects to DTOs, guaranteeing uniformity and lowering human error.
● Changing all impacted controllers to return DTOs rather than complete entity objects,
thereby removing private information such internal IDs, passwords, and privilege flags.
● Completely examining API answers to ensure that only information pertinent to the
business is present.

By separating API contracts from internal database models, this design decreases the attack
surface, improves privacy compliance, and enforces data minimization.
14 | P a g e

Testing Performed
Test Case Description Result

Passed
1. User Endpoint Verified that user data responses exclude
Only username, email,
Validation passwords and admin privilege flags.
and role returned

2. Account Passed
Verified that account responses exclude
Endpoint Only account ID and
internal owner identifiers.
Validation relevant details returned

3. Search Endpoint Ensured no sensitive data appears in user Passed

Validation search results. All responses sanitized

Passed
4. List Endpoint Verified that listing multiple users exposes
All user data limited to
Validation no sensitive fields.
safe attributes

Test Coverage: 100% of affected endpoints

Outcome: All tests were successful, demonstrating that the system complies with OWASP
API3:2023 compliance requirements and that sensitive data is completely excluded from API
responses.
15 | P a g e

Security Fix #5: Rate Limiting Implementation (API4:2023 –

Unrestricted Resource Consumption)
Overview

Rate limiting was implemented on critical API endpoints using the Bucket4j token bucket
algorithm to mitigate abuse, prevent brute-force attempts, and reduce the risk of resource
exhaustion.

Vulnerability

The application previously lacked any mechanism to control the number of requests sent to
sensitive endpoints, such as login, signup, transfer, and search APIs. This flaw allowed attackers
to send an unlimited number of requests, potentially leading to brute-force password attacks,
financial abuse through rapid transactions, user enumeration, and Denial of Service conditions.
The issue aligns with “OWASP API4:2023 – Unrestricted Resource Consumption”,
representing a high-severity threat to system availability and integrity.
16 | P a g e

Fix Implemented

A new “[Link]” component was introduced to enforce per-user and per-IP rate
limiting using the Bucket4j library, based on the token bucket algorithm. Independent rate-
limiting policies were defined for each critical operation:

● Login – 5 attempts per minute per username/IP

● Signup – 3 attempts per minute per IP
● Transfer – 10 operations per minute per user
● Search – 20 queries per minute per user

The service automatically refills tokens over time and currently operates in-memory, with
extensibility options for Redis integration in distributed environments. These configurations
ensure granular control, isolating abuse per user or IP without affecting legitimate traffic.

Testing Performed

Comprehensive validation was conducted through unit, integration, and manual testing:

● Unit Tests verified that request limits trigger appropriate HTTP 429 (“Too Many
Requests”) responses once thresholds are exceeded.
● Integration Tests confirmed seamless interaction between endpoints under normal load
and proper token regeneration behavior.
● Manual Security Testing simulated real-world attack scenarios, including rapid login
attempts and high-frequency API calls, validating consistent rate enforcement and stable
application performance.

All testing outcomes confirmed that the rate limiting effectively mitigates excessive resource
consumption and improves the application’s resilience against automated and abusive traffic.
17 | P a g e

Security Fix #6 — Mass Assignment Protection (API6:2023 –

Unrestricted Access to Sensitive Business Flows)
Overview

Implemented input validation using a dedicated “CreateUserRequest” DTO to prevent mass

assignment by excluding sensitive fields like “role” or “isAdmin”, from client-submitted data.
18 | P a g e

Vulnerability
Previously, the “/api/users” and “/api/auth/signup” endpoints directly accepted the full AppUser
entity, allowing attackers to manipulate sensitive fields in JSON payloads (e.g., "role":
"ADMIN", "isAdmin": true). This led to unauthorized privilege escalation and full administrative
access, violating the principle of least privilege.

Fix Implemented

A new “CreateUserRequest DTO” was introduced to only accept safe fields like username,
password and email, while enforcing strong input validation with Jakarta Bean Validation
annotations like @NotBlank, @Size, @Pattern, and @Email. The UserController and
AuthController now perform:

● Server-side assignment: role="USER", isAdmin=false

● Password hashing: Integrated with BCrypt
● Validation: Enforces unique username and email
● Response hardening: Returns sanitized UserResponseDto

Testing Performed
Automated PowerShell test scripts were executed to validate Fix #6 functionality and confirm
prevention of privilege escalation and data exposure.

Test Case Scenario Expected Result Actual Result Status

1 Create user with "role": Role defaults to Role = "USER", Pass
"ADMIN", "isAdmin": true" "USER", no isAdmin isAdmin not
field returned
2 Login as new user, access 403 Forbidden Access denied Pass
/api/admin/metrics (403)
3 Retrieve user list (GET Password field Password hidden Pass
/api/users) excluded
4 Edge case: "role": "admin" Role defaults to Role = "USER" Pass
lowercase "USER"
19 | P a g e

5 Attempt duplicate Returns 409 Conflict Conflict correctly Pass

username/email raised

Security Fix #7 — JWT Hardening and Token Validation (API2:2023 –

Broken Authentication)
Overview

Implemented a secure JSON Web Token mechanism with strong cryptographic key handling,
short token lifetimes, and strict validation of issuer and audience claims. The fix strengthens
authentication integrity and mitigates risks of token forgery, replay, and misuse across services.
20 | P a g e

Vulnerability

The original JWT implementation suffered from several security flaws:

● No validation of issuer (iss) or audience (aud) claims, allowing cross-application and

cross-service token reuse.
● Excessive token TTL (30 days), increasing the risk window for stolen tokens.
● Weak key management, using raw byte arrays instead of a proper HMAC key.
● Silent failure on validation errors, masking potential tampering.
These issues aligned with API7:2023 - Security Misconfiguration, API8:2023 - Lack of
Protection from Automated Threats, CWE-347, and CWE-613, exposing the system to
token forgery and session hijacking.

Fix Implemented

Security improvements applied to [Link] and [Link]:

1. Added issuer and audience claim validation.

2. Reduced token TTL from 30 days to 15 minutes.
3. Enforced HMAC-SHA key generation with [Link]() (256-bit).
4. Implemented strict signature validation and exception handling.
5. Externalized JWT settings to [Link] for secure configuration.

Testing Performed

# Test Case Description Result

1 Valid Login Token Generation Successful login issues JWT with valid signature & Pass
claims
2 Issuer Claim Validation Tokens missing or mismatched "iss" claim rejected Pass
3 Audience Claim Validation Tokens with invalid "aud" claim rejected Pass

4 Expired Token Handling Expired tokens return 401 Unauthorized Pass

21 | P a g e

5 Malformed Token Detection Invalid token format triggers safe rejection Pass

6 Signature Verification Tampered tokens rejected after signature check Pass

7 Token Replay Protection Old tokens cannot be reused after TTL expiry Pass

8 Environment Key Validation Wrong secret key prevents token validation Pass

9 Claim Tampering Handling Modified payloads correctly denied Pass

10 TTL Enforcement Token expiration validated at 900 seconds (15 min) Pass

11 Exception Logging Validation errors logged securely, no sensitive info Pass

leaked
12 Configuration Isolation Tokens fail validation if config modified externally Pass

13 API Endpoint Authorization Protected routes deny access without valid JWT Pass

14 Cross-Service Token Reuse Tokens from other services (invalid audience) Pass
rejected
22 | P a g e
23 | P a g e

Security Fix #8 — Error Handling and Information Leakage Mitigation

(API7:2023 – Server-Side Request Forgery / Information Exposure)
Overview:
This fix enhances application security by implementing centralized and sanitized error handling
to prevent the disclosure of sensitive system details through verbose error messages. The update
introduces a global exception handler, structured API error responses, and secure server-side
logging. It ensures that users only receive minimal, user-friendly messages while maintaining
detailed diagnostic information in server logs for administrators.

Vulnerability
The previous implementation exposed sensitive internal information such as:

⦁ Exception class names (e.g., [Link]).

⦁ Database schema and constraint names.

⦁ Full application stack traces and framework details.

These leaks could help attackers perform reconnaissance, identify frameworks and database
structures, and craft targeted attacks.

Fix Implemented
Files Modified:

⦁ [Link] (Complete replacement)

⦁ [Link] (Error configuration)

⦁ [Link] (JWT error handling alignment)

 24 | P a g e

Testing Performed

Test Case Scenario Description Status

1 Malformed JSON Parser errors return safe message Pass
2 Validation Errors Field-level errors displayed Pass
cleanly
3 Authentication Failures No username enumeration Pass
4 Access Denied 403 with no internal security Pass
info
5 Database Constraint No schema or SQL info leaked Pass
Violation
6 Stack Trace Exposure Stack traces hidden from users Pass
7 Logging Verification Full details logged internally Pass
8 Error Format Validation All responses follow standard Pass
structure
9 Environment Isolation Prod hides, Dev shows detailed Pass
errors
10 Regression Test Error handling consistent across Pass
modules
25 | P a g e

Security Fix #9 — Input Validation and Business Logic Enforcement

(API8:2023 – Security Misconfiguration / Injection)

Overview
Implements comprehensive input validation for financial transfers to prevent money creation,
integer overflow, and overdraft attacks. The application previously accepted any transfer amount
without validation, including negative values that increased account balances. This fix enforces
strict server-side checks on all transfer requests, ensuring only valid, positive, and bounded
amounts are processed, maintaining both financial and logical integrity.

Vulnerability
● API10:2023 – Unsafe Consumption of APIs
● CWE-20 – Improper Input Validation
● Severity: Critical
26 | P a g e

Fix Implemented
Files Modified:

● [Link] – Added validation method and funds check

● [Link] – Introduced configurable transaction limits

Testing Performed
Test Case Test Case Name Input Status
1 Negative Amount Test -100 Passed
2 Zero Amount Test 0 Passed
3 Huge Amount Test 999999999 Passed
4 Below Minimum Amount Test 0.001 Passed
5 Above Maximum Amount Test 200000 Passed
6 Non-Numeric Input Test abc Passed
7 SQL Injection Test 100’ OR 1=1 Passed
8 Insufficient Funds Test balance+100 Passed
27 | P a g e

Security Fix #10 — Integration Testing for Security Verification (Cross-

cutting Control)
Overview
This fix ensures that the security measures applied across the system—such as authentication,
authorization, and data access restrictions—function correctly when different components
interact. Integration testing was performed to confirm that endpoints, security filters, and
database configurations collectively enforce the intended access rules and prevent unauthorized
data exposure or privilege escalation.

Vulnerability

Before the fix, although individual security configurations (like role-based restrictions) were
implemented, there was no integrated verification to ensure these rules worked together under
real runtime conditions. This gap could have led to:

● Unauthorized access to protected endpoints.

● Role or privilege misuse due to missing validation layers.

● Security misconfigurations in the Spring Security context not being detected until
deployment.

Fix Implemented

Comprehensive integration tests were introduced to verify end-to-end security behavior using
Spring Boot’s testing framework. The following updates were applied:

● Implemented additional test cases under [Link].

● Added assertions to ensure user “alice” (role: USER) cannot access or modify “bob”’s
account balance.
28 | P a g e

● Verified that security configurations correctly return HTTP 403 Forbidden responses for
unauthorized actions.

● Confirmed that only users with the appropriate roles can execute sensitive operations, as
shown in the database (APP_USER table).

These integration tests act as automated guards against future regressions in security logic.
29 | P a g e

Testing Performed

Test Case Scenario Input Output Status

1 Access own account GET 200 OK Pass

balance /api/accounts/{alice
}/balance

2 Access another user’s GET 403 Forbidden Pass

balance /api/accounts/{bob}/
balance

3 Admin accessing another GET 200 OK Pass

user’s balance /api/accounts/{alice
}/balance

4 Unauthorized user (no GET 401 Unauthorized Pass

token) /api/accounts/{alice
}/balance

5 Database role verification H2 Console – Verified Pass

SELECT * FROM
APP_USER
30 | P a g e
31 | P a g e