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

[anupamme]

The OpenAPI specification explicitly declares security: [] (empty array) at the root level, documenting all booking endpoints as requiring no authentication. This includes POST /v2/bookings (create booking), PUT /v2/bookings/{bookingReference} (update booking), and GET /v2/bookings/{bookingReference} (retrieve booking). The specification covers critical shipping operations including dangerous goods cargo handling and confirmed booking modifications. The affected code is bkg/v2/BKG_v2.0.0.yaml:1. This change is the fix I would apply.

Reference: CWE-306

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.

---

Automated security fix by OrbisAI Security

[qodo-code-review]

PR Summary by Qodo

Require JWT bearer authentication in Booking API v2.0.0

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

AI Description

• Requires JWT bearer authentication across all Booking API operations.
• Defines a reusable HTTP bearer security scheme with JWT formatting.

Diagram

graph TD
  Spec["BKG v2.0.0"] --> Root["Root Security"] --> Scheme["BearerAuth JWT"]
  Root --> Create["Create Booking"]
  Root --> Update["Update Booking"]
  Root --> Retrieve["Retrieve Booking"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Declare security per operation

• ➕ Makes authentication requirements explicit on each endpoint
• ➕ Allows selected operations to remain anonymous
• ➖ Duplicates declarations across the specification
• ➖ Creates a greater risk of omissions and inconsistent requirements

Recommendation: Keep the root-level BearerAuth requirement because the stated policy applies to every Booking API operation and inheritance minimizes duplication. Reviewers should confirm that no endpoint is intentionally public and that implementations or gateways actually validate JWTs, since the OpenAPI declaration alone does not enforce authentication at runtime.

Files changed (1) +7 / -1

Other (1) +7 / -1

BKG_v2.0.0.yamlRequire JWT bearer authentication for Booking API operations +7/-1

Require JWT bearer authentication for Booking API operations

• Replaces the anonymous global security declaration with a BearerAuth requirement inherited by all operations. Adds a reusable HTTP bearer security scheme identifying JWT as the 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. Valid integrations lose authentication choice 🐞 Bug ≡ Correctness

Description

The root security requirement makes JWT bearer authentication mandatory for every operation,
including the consumer-hosted /v2/booking-notifications callback whose subscription setup is
explicitly outside this specification. Integrations using another bilateral authentication mechanism
therefore conflict with this isolated 2.0.0 contract, while every subsequent Booking 2.0.x
specification continues to declare no standardized security mechanism.

Code

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

+security:
+  - BearerAuth: []

Evidence

The specification states that notifications are pushed to endpoints implemented by consumers and
that notification signup is outside its scope, yet the new root requirement covers that callback as
well as all provider operations. The repository describes its standards as technology-agnostic, and
Booking versions 2.0.1, 2.0.2, and 2.0.5 all retain security: [], showing that JWT is not part of
the shared Booking 2.0.x contract.

bkg/v2/BKG_v2.0.0.yaml[24-39]
bkg/v2/BKG_v2.0.0.yaml[59-60]
bkg/v2/BKG_v2.0.0.yaml[1798-1807]
bkg/v2/BKG_v2.0.0.yaml[2249-2253]
README.md[3-4]
bkg/v2/BKG_v2.0.1.yaml[56-56]
bkg/v2/BKG_v2.0.2.yaml[56-56]
bkg/v2/BKG_v2.0.5.yaml[56-56]

Agent prompt

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

## Issue description
The root security declaration incorrectly mandates JWT bearer authentication across all Booking operations and consumer-hosted notification callbacks, although authentication arrangements are outside this technology-agnostic specification.

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

## Recommended Fix
Restore the root `security: []` declaration and remove the `BearerAuth` security scheme. Authentication must be enforced by each implementation or standardized separately with all supported mechanisms and endpoint roles defined.

ⓘ 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 contract change that alters authentication requirements for booking endpoints, warranting a complete careful review.

Tip of the day

💡 Did you know, you can choose which labels appear on a finding, and whether they show icons or text

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Valid integrations lose authentication choice 🐞 Bug ≡ Correctness

The root security requirement makes JWT bearer authentication mandatory for every operation,
including the consumer-hosted /v2/booking-notifications callback whose subscription setup is
explicitly outside this specification. Integrations using another bilateral authentication mechanism
therefore conflict with this isolated 2.0.0 contract, while every subsequent Booking 2.0.x
specification continues to declare no standardized security mechanism.

Agent Prompt

## Issue description
The root security declaration incorrectly mandates JWT bearer authentication across all Booking operations and consumer-hosted notification callbacks, although authentication arrangements are outside this technology-agnostic specification.

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

## Recommended Fix
Restore the root `security: []` declaration and remove the `BearerAuth` security scheme. Authentication must be enforced by each implementation or standardized separately with all supported mechanisms and endpoint roles defined.

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

[HenrikHL]

Hi @anupamme - thank you for the suggestion. We don't define or include authentication as part of the standard. This has to be defined outside the scope of the API. When you copy the spec and document it on your site - authentication would be expected. You are free to modify the spec "locally".
Apart from that - a published version (3.0.0) cannot be modified. Any modifications need to be towards a new patch