feat(core): add asyncapi security-defined lint rule#2759
Conversation
🦋 Changeset detectedLatest commit: fb2fcb2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
vadyvas
left a comment
There was a problem hiding this comment.
I would suggest a slightly different approach:
- keep the AsyncAPI logic separate and do not reuse shared logic from the OAS rule
- use the same rule name,
security-defined, for AsyncAPI as well, and register the AsyncAPI implementation in the AsyncAPI ruleset - do not update the v1 docs in this PR
I think this would make the change smaller, clearer, and safer.
Thank you for the contribution, overall the PR looks good
vadyvas
left a comment
There was a problem hiding this comment.
left a few comments, could you take a look?
| 'info-contact': InfoContact as Async2Rule, | ||
| 'info-license-strict': InfoLicenseStrict as Async2Rule, | ||
| 'operation-operationId': OperationOperationId as Async2Rule, | ||
| 'security-defined': SecurityDefined, |
There was a problem hiding this comment.
Please add support for AsyncAPI 3 as well. Right now the rule only applies to AsyncAPI2
There was a problem hiding this comment.
The code uses the rule name security-defined, but the docs still say asyncapi-operation-security-defined
Can you update related changes?
| @@ -0,0 +1,83 @@ | |||
| # asyncapi-operation-security-defined | |||
There was a problem hiding this comment.
Please don’t add this rule to the v1 docs
Performance Benchmark (Lower is Faster)
|
|
Hey @DmitryAnansky , I have fixed all comments and failing e2e tests and PR is good to review again. Thanks ! |
| ); | ||
| }); | ||
|
|
||
| it('should call createTestContext for arazzo type using the spec form without `workflows` segment', async () => { |
There was a problem hiding this comment.
Why do we need those changes?
There was a problem hiding this comment.
I missed the existing check which was already present hence I agree with you and I should remove this.
| type SecuredOperation = Async2Operation | Async3Operation; | ||
| type SecuredTrait = Async2OperationTrait | Async3OperationTrait; | ||
|
|
||
| export function isOperationSecured( |
There was a problem hiding this comment.
Could you move this function under the file packages/core/src/rules/utils.ts. Also, please take a look to the @DmitryAnansky 's comment regarding the name of the function.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 99f2ba7. Configure here.
|
Hey @Daryna-del , I have addressed all the comments left by you and cursor and also resolved the failing e2e tests. Can you review the recent changes again ? Thanks ! |

What/Why/How?
asyncapi-operation-security-definedrule for AsyncAPI 2.x which reports when a security scheme referenced from an operation or serversecurityarray is not defined in ``components.securitySchemes.Reference
#2667
Testing
Screenshots (optional)
Check yourself
Security
Note
Medium Risk
New
error-level rule in recommended rulesets can break existing AsyncAPI CI; logic touches security semantics and server/channel applicability.Overview
Adds a
security-definedbuilt-in rule for AsyncAPI 2.x and 3.x, aligned with the existing OpenAPI rule: it validates security scheme references and whether operations are covered by security.For 2.x, operation/server
securityentries must name schemes undercomponents.securitySchemes. Operations without their ownsecuritymust be satisfied by all applicable servers (channel server bindings, traits included via newisAsyncOperationSecured).For 3.x, security
$refs must target#/components/securitySchemes/{name}and resolve; rootoperationsget the same “operation or applicable servers” checks.The rule is registered in minimal (
warn), recommended / recommended-strict / all (error), with docs, sidebar, and a minor changeset noting that recommended AsyncAPI lint may newly fail. Typings and AsyncAPI visitors are extended to support the rule; AsyncAPI split CLI code gets a smallAnyAsyncApiComponentstyping tweak.Reviewed by Cursor Bugbot for commit fb2fcb2. Bugbot is set up for automated code reviews on this repo. Configure here.