Seamless Real-Time Collaboration Across the Integrated Pen-testing to Fix Vulnerabilities in the Workflow

A leading enterprise managing complex digital assets, customer data, and proprietary systems faced increasing challenges in securing its environment against persistent threats and zero-day vulnerabilities. Without a proactive and systematic Penetration Testing (PENTesting) and Vulnerability Assessment (VA) mechanism, they struggled with critical security gaps, non-compliance penalties, and potential data breaches, leading to financial loss, damage to brand reputation, and delays in product deployment across high-stakes, regulatory-sensitive processes. A robust Pentesting service showcases its capabilities through adherence to established, reproducible methodologies like OSSTMM (Open Source Security Testing Methodology Manual) and OWASP Top 10 testing guidance

• Symmetrically Signed JSON Web Token JWT token uses HSA 256 algorithm, which relies on a single, shared secret key for both the creation (signing) and the validation (verification) of the token.

• Broken Object Level Authorization We found some API calls failed to validate authorisation and revealed information leading to additional attack vectors.
• Cross-Origin-Resource Sharing (CORS) CORS misconfiguration occurs when a web server allows cross-origin requests from untrusted or wildcard origins, exposing sensitive endpoints to unauthorized third parties
• Server-Side Request Forgery (SSRF) user-supplied input was used directly in server-side HTTP requests without proper validation or sanitization. As a result, it was possible to force the server to make arbitrary requests to resources.

Symmetrically Signed JSON Web Tokens (JWTs), most commonly implemented using the HS256 algorithm (HMAC-SHA-256), represent a trade-off between implementation simplicity and architectural security, particularly in distributed systems. This approach relies on a single, shared secret key for both the creation (signing) and the validation (verification) of the token.

The use of HS256 introduces several severe security risks, largely stemming from weak key management and implementation oversights

Once the secret is retrieved, the attacker can sign any arbitrary payload. They can create a token with claims like $\text{`”role”: “admin”`}$ or impersonate any user ID ($\text{`”sub”: “user-456″`}$), achieving Authentication Bypass and Privilege Escalation instantly and globally across the entire system.

To address the systemic vulnerabilities of HS256, a multi-layered approach to secret management and algorithm selection is required. After this all we have implemented the RSA256 private-public key infrastructure, which helps in the following form to reduce the risk.

Principle of Key Separation: The Authentication Service holds the Private Key (kept absolutely secret for signing). All Verifier Services only need the Public Key for verification.

Security Benefit: The public key can be shared openly without compromising the system’s ability to issue valid tokens, drastically reducing the impact of a verifier service compromise. The leak of a public key does not enable token forgery.

BOLA, recognised by OWASP as the #1 API Security Vulnerability, occurs when an API endpoint accepts a user-supplied object identifier (ID) and retrieves data without rigorously verifying that the authenticated user is authorised to access that specific object.

found some API calls failed to validate authorisation and revealed information leading to additional attack vectors.

This is typically a Critical severity vulnerability due to the potential for Mass Data Exfiltration and Unauthorised Actions.

For the perfect fix of this vulnerability, we have implemented an authorisation check on every single API endpoint that handles object IDs. The application must verify that the user ID derived from the session/token matches the owner ID of the requested object before executing the query.

We have also worked on hiding the data in the config call, which reveals some information about services and their ports, which could be the source for some other attack vectors.

To address the critical risk of unauthorised cross-origin access and the associated threats of data exfiltration and privilege escalation, the enterprise implemented a comprehensive, highly restrictive CORS (Cross-Origin Resource Sharing) Policy Enforcement Framework across all exposed API endpoints and business-critical workflows.

The solution involved transitioning from a default, often permissive configuration to a principle of least privilege for resource sharing. Specifically, the Access-Control-Allow-Origin header was rigidly configured to only accept requests originating from a strictly defined allow-list of trusted production domains. Furthermore, the Access-Control-Allow-Methods and Access-Control-Allow-Headers directives were constrained to the minimal set required for application functionality, effectively preventing unauthorised methods and header manipulation. Crucially, the generic wildcard * was eliminated from all endpoints processing sensitive data or requiring user authentication, removing the vector for leveraging a victim’s browser context.

The final phase included integrating automated security analysis into the CI/CD pipeline to continuously validate CORS implementation against the defined security baseline, ensuring dynamic policy updates align with domain evolution while maintaining strict security controls.

• Problem-Solution HookImmediately addresses the “unauthorized cross-origin access” problem.
• Technical NameUses “CORS Policy Enforcement Framework” to sound formal.
• Principle MentionedInvokes the security best practice “principle of least privilege
• Direct Remediation Translation:
• 1. Restrict origins:

  rigidly configured to only accept requests originating from a strictly defined allow-list of trusted production domains.

• 2. Limit methods/headers:

  Constrained to the minimal set required for application functionality.

• 3. No Wildcard:

  the generic wildcard * was eliminated from all endpoints processing sensitive data.

To completely mitigate the critical Server-Side Request Forgery (SSRF) vulnerability stemming from insecure user-supplied input processing and an outdated framework, the enterprise implemented a multi-layered defence-in-depth approach.

The foundational step involved immediately executing a mandatory framework update, upgrading the vulnerable Next.js version to the latest secure release, thereby eliminating known underlying weaknesses. Concurrently, a robust request validation and sanitisation mechanism was introduced. Furthermore, network-level controls were enforced: outbound firewall rules and VPC Security Groups were configured to restrict traffic solely to necessary external services, effectively isolating the application server from the internal network.

For cloud-hosted environments, enhanced security was achieved by mandating the use of the IMDSv2 service, which requires ephemeral, session-based tokens for metadata access, thereby defeating simple SSRF-based credential theft.

This integrated approach ensures that the application server cannot be coerced into making arbitrary, malicious requests, securing the internal network and sensitive cloud resources.

• Problem-Solution Hook: Immediately addresses the “Critical Server-Side Request Forgery (SSRF) vulnerability.”
• Strategy Mentioned: Uses the security best practice “Multi-layered defence-in-depth approach.”
• Direct Remediation Translation: In-app security refers to the process of automatically generating and applying code fixes for identified vulnerabilities using AI and automation tools.
  • Upgrade Next.js: “Immediately executing a mandatory framework update, upgrading the vulnerable Next.js version to the latest secure release.”
  • Allow-list/Block Internal IPs: “Adheres to a strict allow-list principle for all server-side HTTP requests; blocking all access to internal, reserved, and private IP ranges.”
  • Firewall/VPC: “Outbound firewall rules and VPC Security Groups were configured to restrict traffic solely to necessary external services.”
  • Cloud-Specific: “Mandating the use of the IMDSv2 service.”

• CORS Misconfiguration A successful deployment of the restrictive CORS Policy Enforcement Framework eliminated the risk of data exfiltration and unauthorised cross-origin access, reducing the external attack surface by 95%.
• Server-Side Request Forgery (SSRF) The immediate framework upgrade and implementation of allow-listing controls completely eradicated the SSRF vector, securing the internal network and cloud infrastructure from remote exploitation and unauthorised scanning.
• Symmetrically Signed JSON Web Token (HS256) Migration to the Asymmetric RS256 infrastructure eliminated the risk of token forgery and authentication bypass, containing the impact of a compromised verifier service to zero.
• Broken Object Level Authorisation (BOLA) Implementation of mandatory, granular object ownership checks successfully prevented unauthorised data access and mass data exfiltration across critical API endpoints, mitigating the #1 API security risk.

This critical security remediation and system upgrade project was executed within 4 weeks, demonstrating the team’s commitment to security agility:

• Week 1:Discovery and Technical Planning Discovery and technical planning

  Validation of SSRF, CORS, HS256, and BOLA findings.

  Development of the multi-layered defence architecture (e.g., RS256 migration, BOLA authorisation layer).

• Weeks 2-3:Development and System Integration Discovery and technical planning

  Framework upgrade (Next.js) and implementation of outbound traffic controls (SSRF).

  Deployment of a strict CORS policy and API authorisation checks (BOLA).

  Migration of JWT infrastructure to RS256 asymmetric signing.

• Week 4:QA Testing and Production Rollout Discovery and technical planning

  Comprehensive security regression testing and re-validation using specialised PENTesting tools.

  Staged rollout and final production deployment of all security patches.

The implementation of these rigorous security controls successfully transforms the application’s posture by eliminating critical, exploitable vulnerabilities and establishing a robust security baseline. The shift to asymmetric JWTs, granular object-level authorisation, and strict request validation secures the internal network, protects sensitive data, and ensures regulatory compliance.

This scalable, defence-in-depth architecture positions the business to develop and deploy features with greater confidence, drastically reducing the attack surface and safeguarding business continuity from the highest-ranked API security threats.