deprecate: API-based pull parsers, Tool Type/Configuration, and dbbackup (3.2.0 → 3.5.0 EOL)

[Maffooch]

Shortcut: sc-13944

Description

Formally deprecates the API-based (pull) parsers, the Tool Type / Tool Configuration feature, and the django-dbbackup integration in 3.2.0, with planned removal in 3.5.0 (November 2026) — a full quarter of deprecation runway. Based on the maintainer decision thread.

Rationale

• API-pull integrations (the 6 api_* parsers: BlackDuck, Bugcrowd, Cobalt.io, Edgescan, SonarQube, Vulners) are being consolidated into DefectDojo Pro's no-code connectors.
• Tool Type / Tool Configuration exist only to configure those pull parsers; after the CI/CD infrastructure split (Split CI/CD-related infrastructure into its own model  #15002) they have no other consumers, so they are removed at the same time as the parsers.
• django-dbbackup is minimally integrated and its pg_dump-based backup fails on PostgreSQL client/server version skew (see The dbbackup funktion in the manage.py script is not working because of server version mismatch #15301).

Changes

• Docs: deprecation notices + timeline in docs/content/releases/os_upgrading/3.2.md; legacy upgrade stub repointed.
• API: X-Deprecated / X-End-Of-Life-Date response headers on the Tool Configuration, Tool Type, and Product/Asset API Scan Configuration viewsets via DeprecationNoticeMixin. The mixin is placed first in the MRO so finalize_response actually runs (listing it last makes it dead code).
• UI: deprecation banners on the Tool Configuration, Tool Type, and per-product API Scan Configuration pages — rendering on both the new and classic UIs via the messages framework.
• Tests: assert the deprecation headers on the affected endpoints.

Nothing is removed in this PR — removal is tracked for 3.5.0 (state-only migrations, following the stub-finding / credential-manager pattern).

Open items to reconcile (non-blocking)

• "Coverity API" is a file parser (not one of the 6 pull parsers) — kept out of scope; reconcile the customer list with the Pro migration.
• Edgescan/Vulners also accept an uploaded file; the file-import path's fate at 3.5.0 to be confirmed.

🤖 Generated with Claude Code

[dryrunsecurity]

This pull request introduces multiple critical and high-severity Insecure Direct Object Reference (IDOR) vulnerabilities in various views, including edit_tool_type, edit_tool_config, and API scan configuration functions. These issues arise from missing explicit authorization checks, allowing unauthorized users to potentially access or modify sensitive objects by manipulating ID parameters.

🔴 Potential IDOR Vulnerability in dojo/tool_type/ui/views.py (drs_bf3fa05e)

Vulnerability	Potential IDOR Vulnerability
Description	The edit_tool_type view retrieves a Tool_Type object directly from a user-controlled path parameter with Tool_Type.objects.get(pk=ttid) and the function has no user-scoped query, ownership check, or authorization decorator. The added deprecated_view decorator only shows a warning message and does not restrict access, so changing ttid can expose another object.

django-DefectDojo/dojo/tool_type/ui/views.py

Lines 40 to 41 in 0d8a1f9

	tool_type = Tool_Type.objects.get(pk=ttid)
	if request.method == "POST":

🔴 Potential IDOR Vulnerability in dojo/tool_config/ui/views.py (drs_ada348c4)

Vulnerability	Potential IDOR Vulnerability
Description	The edit_tool_config UI view fetches a Tool_Configuration directly by the caller-controlled ttid primary key and then allows that object to be edited, with no object-level authorization check, ownership filter, or permission decorator shown in the view or URL wiring. The added @deprecated_view(...) decorator only emits a warning message and does not enforce access control.

django-DefectDojo/dojo/tool_config/ui/views.py

Lines 55 to 56 in 0d8a1f9

	tool_config = Tool_Configuration.objects.get(pk=ttid)
	if request.method == "POST":

🟠 IDOR in edit_tool_type View in dojo/tool_type/ui/views.py (drs_76ba6167)

Vulnerability	IDOR in edit_tool_type View
Description	The edit_tool_type view in dojo/tool_type/ui/views.py lacks explicit authorization checks to verify if the current user has permission to edit the specified tool type. While the view is deprecated, it remains functional and accessible, potentially allowing unauthorized users to modify tool types if they can guess or discover valid 'ttid' values.

django-DefectDojo/dojo/tool_type/ui/views.py

Lines 39 to 40 in 0d8a1f9

	def edit_tool_type(request, ttid):
	tool_type = Tool_Type.objects.get(pk=ttid)

🟠 IDOR in add_api_scan_configuration in dojo/product/ui/views.py (drs_09a30758)

Vulnerability

IDOR in add_api_scan_configuration

Description

The add_api_scan_configuration view in dojo/product/ui/views.py retrieves the product using get_object_or_404(Product, id=pid). While this ensures the product exists, it does not explicitly verify if the current user has authorization to access or modify that specific product. The view lacks an explicit authorization decorator or check (e.g., user_has_permission_or_403) to ensure the user is authorized for the given product ID.

django-DefectDojo/dojo/product/ui/views.py

Lines 1710 to 1711 in 0d8a1f9

	product = get_object_or_404(Product, id=pid)
	if request.method == "POST":

🟠 IDOR in view_api_scan_configurations in dojo/product/ui/views.py (drs_8f4b0bd8)

Vulnerability

IDOR in view_api_scan_configurations

Description

The view_api_scan_configurations function in dojo/product/ui/views.py lacks an explicit authorization check to verify if the current user has permission to access the specified product (pid). While other functions in the same file (e.g., add_product_authorized_users) use user_has_permission_or_403, this view does not, potentially allowing unauthorized users to view API scan configurations for products they are not authorized to access.

django-DefectDojo/dojo/product/ui/views.py

Lines 1753 to 1755 in 0d8a1f9

	def view_api_scan_configurations(request, pid):
	product_api_scan_configurations = Product_API_Scan_Configuration.objects.filter(product=pid)

We've notified @mtesauro.

---

Comment to provide feedback on these findings.

Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]

Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing

All finding details can be found in the DryRun Security Dashboard.