fix: add authentication check in BKG_v2.0.0.yaml (CWE-287)

[anupamme]

The OpenAPI specification files explicitly define 'security: []' at the root level, indicating no authentication is required for any API endpoints. This shipping booking system handles dangerous goods cargo declarations, vessel bookings, and commercial shipping data. All 20+ database operations for booking management are accessible without any authentication mechanism. The affected code is bkg/v2/BKG_v2.0.0.yaml:1, and this change addresses it.

Reference: CWE-287

What changed

• bkg/v2/BKG_v2.0.0.yaml

Verification

No automated check could be run against this repository, so this change is unverified beyond review. Please treat it as a suggestion.

[qodo-code-review]

PR Summary by Qodo

Require bearer authentication for Booking API v2

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Replaces the unauthenticated global policy with bearer authentication.
• Defines JWT bearer authentication in the OpenAPI components.
• Applies the security requirement to every Booking API operation.

Diagram

graph TD
  Spec["Booking OpenAPI"] -->|declares| Global["Global Security"] -->|references| Scheme["Bearer JWT"] -->|applies to| Ops["All Operations"]

Loading

High-Level Assessment

The global bearer requirement is the appropriate minimal fix because all documented operations handle sensitive shipping data. Declaring security per operation would duplicate configuration and risk omissions, while OAuth2 flows would require authorization-server and scope details not established by this specification. Implementations must still perform runtime JWT validation because the OpenAPI declaration alone does not enforce authentication.

Files changed (1) +7 / -1

Bug fix (1) +7 / -1

BKG_v2.0.0.yamlRequire JWT bearer authentication across Booking API v2 +7/-1

Require JWT bearer authentication across Booking API v2

• Replaces the root-level empty security requirement with a global bearer authentication requirement. Adds an HTTP bearer security scheme using JWT as the documented token format.

bkg/v2/BKG_v2.0.0.yaml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Clients receive conflicting authentication 🐞 Bug ≡ Correctness

Description

security now makes bearer authentication mandatory for every 2.0.0 operation without changing the
published API version, while every subsequent 2.0.x contract still declares security: [].
Consumers regenerating against 2.0.0 or moving among patch releases therefore receive incompatible
authentication requirements and must alter integration behavior despite using the same API
generation.

Code

bkg/v2/BKG_v2.0.0.yaml[R59-60]

+security:
+  - bearerAuth: []

Evidence

The changed root requirement applies bearer authentication to every 2.0.0 operation, including the
independently consumer-implemented notification endpoint. Versions 2.0.1 through 2.0.5 retain an
explicit empty security requirement, and the release documentation identifies 2.0.0 as a final
published version followed by patch releases, proving that this change creates contradictory
contracts within the same API generation.

bkg/v2/BKG_v2.0.0.yaml[59-60]
bkg/v2/BKG_v2.0.0.yaml[1798-1808]
bkg/v2/BKG_v2.0.1.yaml[52-56]
bkg/v2/BKG_v2.0.5.yaml[52-56]
bkg/v2/README.md[56-86]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Adding mandatory bearer authentication only to the published 2.0.0 specification creates an incompatible contract relative to versions 2.0.1 through 2.0.5, all of which explicitly disable security.

## Fix Focus Areas
- bkg/v2/BKG_v2.0.0.yaml[59-60]
- bkg/v2/BKG_v2.0.0.yaml[2249-2253]
- bkg/v2/README.md[56-86]

## Recommended Fix
Do not mutate the released 2.0.0 authentication contract in place. Restore its existing security declaration and introduce mandatory authentication through a properly versioned release, updating the currently supported specification and release documentation consistently.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: ⚖️ Balanced: This is a security-sensitive OpenAPI authentication contract change affecting all booking endpoints, warranting a complete careful review.

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Clients receive conflicting authentication 🐞 Bug ≡ Correctness

security now makes bearer authentication mandatory for every 2.0.0 operation without changing the
published API version, while every subsequent 2.0.x contract still declares security: [].
Consumers regenerating against 2.0.0 or moving among patch releases therefore receive incompatible
authentication requirements and must alter integration behavior despite using the same API
generation.

Agent Prompt

## Issue description
Adding mandatory bearer authentication only to the published 2.0.0 specification creates an incompatible contract relative to versions 2.0.1 through 2.0.5, all of which explicitly disable security.

## Fix Focus Areas
- bkg/v2/BKG_v2.0.0.yaml[59-60]
- bkg/v2/BKG_v2.0.0.yaml[2249-2253]
- bkg/v2/README.md[56-86]

## Recommended Fix
Do not mutate the released 2.0.0 authentication contract in place. Restore its existing security declaration and introduce mandatory authentication through a properly versioned release, updating the currently supported specification and release documentation consistently.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools