Use a dedicated permission class for BurpRawRequestResponseViewSet#14838
Merged
Maffooch merged 2 commits intoDefectDojo:bugfixfrom May 8, 2026
Merged
Conversation
The top-level /api/v2/request_response_pairs/ viewset reused UserHasFindingRelatedObjectPermission, which is shaped for @action(detail=True) endpoints where DRF resolves the parent finding from the URL. On a top-level POST there is no parent object resolved yet, so the create flow only ran has_object_permission against the not-yet-saved row and effectively skipped any check on the client-supplied "finding" foreign key. Introduce UserHasBurpRawRequestResponsePermission, which validates the parent finding against Finding_Edit on POST via check_post_permission, mirroring the pattern already used by UserHasFindingPermission, UserHasProductPermission, and the other parent-keyed viewsets. has_object_permission dereferences obj.finding for retrieve/update/delete so list/detail/PUT/PATCH/DELETE behavior is unchanged. Add regression coverage in unittests/test_rest_framework.py asserting the positive control still works, that an authenticated user without membership cannot create a pair on a hidden finding, and that POSTs missing the finding key are rejected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The dojo_testdata.json fixture contains Endpoint rows, which raise NotImplementedError in Endpoint.__init__ when V3_FEATURE_LOCATIONS is enabled. Mirror the surrounding API test classes by applying the @versioned_fixtures decorator so the locations-aware fixture is loaded on the V3 matrix leg. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
valentijnscholten
approved these changes
May 8, 2026
Jino-T
approved these changes
May 8, 2026
paulOsinski
approved these changes
May 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The top-level
/api/v2/request_response_pairs/viewset previously reusedUserHasFindingRelatedObjectPermission, aBaseRelatedObjectPermissionsubclass whosehas_permissionreturnsTrue. That class is shaped for@action(detail=True, …)endpoints where DRF resolves the parentFindingfrom the URL andhas_object_permissionruns against it. On a top-levelPOSTthere is no parent object resolved yet, so the create flow only ranhas_object_permissionagainst the not-yet-saved row and skipped any check on the client-suppliedfindingforeign key.This PR introduces
UserHasBurpRawRequestResponsePermission, mirroring the pattern already used byUserHasFindingPermission,UserHasProductPermission, and the other parent-keyed viewsets:has_permissioncallscheck_post_permission(request, Finding, "finding", Permissions.Finding_Edit)onPOST, which fetches the referenced finding and rejects with403/404unless the user hasFinding_Edit. Missingfindingis rejected withParseError.has_object_permissiondereferencesobj.findingfor retrieve/update/delete so list/detail/PUT/PATCH/DELETE behavior is unchanged.The other 11 callers of
UserHasFindingRelatedObjectPermissionare all@action(detail=True, …)decorators where the URL-resolved finding makes the existing class behave correctly, so the base class is left as-is.Test plan
Added
unittests.test_rest_framework.RequestResponsePairsAuthzTestcovering:201and the row count increases.404forGET /api/v2/findings/7/and a 4xx forPOST /api/v2/request_response_pairs/with that finding ID; the row count is unchanged.findingreturns 4xx (theParseErrorpath incheck_post_permission).🤖 Generated with Claude Code