Workflow

[ucswift]

No description provided.

[request-info]

Thanks for opening this, but we'd appreciate a little more information. Could you update it with more details?

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch workflow

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

In general, POST endpoints that can be called from a browser and that perform state‑changing operations should validate an anti‑forgery token (or use another CSRF mitigation). In ASP.NET Core MVC, this is typically done by decorating the action (or controller) with [ValidateAntiForgeryToken] or [AutoValidateAntiforgeryToken] and ensuring the client includes the token with the request.

For this specific method, the minimal change that adds CSRF protection without altering existing business logic is to decorate SendVerificationCode with [ValidateAntiForgeryToken]. ASP.NET Core’s antiforgery attribute lives in Microsoft.AspNetCore.Mvc, which is already imported at the top of the file, so no new using directives are required. The attribute should be added just above the SendVerificationCode action, alongside the existing [HttpPost("SendVerificationCode")] and response type attributes. No changes are needed to the method body.

Concretely:

• In Web/Resgrid.Web.Services/Controllers/v4/ContactVerificationController.cs, locate the SendVerificationCode action.
• Add [ValidateAntiForgeryToken] above its signature (after the existing [HttpPost("SendVerificationCode")] is a reasonable place).
• No other modifications (imports, method definitions, etc.) are necessary in the shown snippet.

---

In general, to fix missing CSRF validation for ASP.NET Core MVC actions, you add an anti-forgery validation attribute (or filter) on each state-changing action method or configure a global filter that enforces validation for all unsafe HTTP methods. For individual methods, this typically means decorating them with [ValidateAntiForgeryToken] when using the built‑in anti‑forgery system. For APIs that are intended to be used from browsers with cookie-based authentication, this ensures that POST requests must include a valid CSRF token.

For this specific method, the minimal, behavior-preserving fix is to add the [ValidateAntiForgeryToken] attribute to the Create action while leaving its logic intact. Since the file already imports Microsoft.AspNetCore.Mvc, where ValidateAntiForgeryTokenAttribute resides, no new using directives are necessary. The attribute should be applied directly above the Create method (typically alongside the existing [HttpPost("Create")], [ProducesResponseType], and [Authorize] attributes). No other methods are shown as flagged, so no further edits are strictly required based on the provided snippet.

Concretely:

• In Web/Resgrid.Web.Services/Controllers/v4/WorkflowCredentialsController.cs, locate the Create action.
• Add [ValidateAntiForgeryToken] as a new attribute line above the method signature (e.g., between [ProducesResponseType] and [Authorize], or next to them).
• No additional imports or helper methods are needed because ValidateAntiForgeryToken is part of Microsoft.AspNetCore.Mvc.

In general, the fix is to ensure that all state-changing POST actions that are reachable from a browser and rely on cookie-based authentication validate an anti-forgery token. In ASP.NET Core MVC, this is typically done via the [ValidateAntiForgeryToken] attribute on the action (or controller) combined with generating the token in the client (e.g., via form fields or headers).

For this concrete method, the minimal change that does not alter existing business logic is to add the ASP.NET Core anti-forgery validation attribute to the Save action. Since this is an API-style controller, the most appropriate attribute is [ValidateAntiForgeryToken] or (for APIs that send the token in headers) [AutoValidateAntiforgeryToken]. To strictly follow the CodeQL recommendation text you provided (which names [ValidateAntiForgeryToken]), we will add [ValidateAntiForgeryToken] directly above the Save method declaration. No other logic in the body needs to change. The necessary type (ValidateAntiForgeryTokenAttribute) is already available from Microsoft.AspNetCore.Mvc, which is already imported at the top of the file, so no new using statements or packages are required.

Concretely:

• In Web/Resgrid.Web.Services/Controllers/v4/WorkflowsController.cs, locate the Save action.
• Add a [ValidateAntiForgeryToken] attribute between [HttpPost("Save")] and [ProducesResponseType(...)] (or adjacent to the other attributes) on that method.
• No additional methods or definitions are necessary in this file for validation; anti-forgery services are configured in application startup, which we are not modifying here.

In general, to fix this kind of issue in ASP.NET Core, you ensure that every state-changing endpoint (especially those using cookie-based authentication) either has explicit CSRF/antiforgery validation (e.g., via [ValidateAntiForgeryToken] or [AutoValidateAntiforgeryToken]) or is clearly excluded because it uses a CSRF-resistant mechanism (e.g., bearer tokens with no cookies). For MVC controllers, the standard approach is to add [ValidateAntiForgeryToken] on each POST/PUT/DELETE action or configure a global filter so that these actions automatically validate the antiforgery token.

For this specific SaveStep method, the smallest and clearest fix without changing existing behavior is to decorate the action with [ValidateAntiForgeryToken]. This keeps the route, parameters, and logic identical, while enforcing that callers provide a valid antiforgery token. ASP.NET Core defines ValidateAntiForgeryTokenAttribute in Microsoft.AspNetCore.Mvc, which is already imported at the top of the file, so no new using directives are required. The attribute should be added alongside the existing [HttpPost("SaveStep")], [ProducesResponseType], and [Authorize] attributes. No changes are needed to the body of SaveStep. If other POST actions in this controller are also browser-exposed, they might deserve similar treatment, but the CodeQL finding is specifically about SaveStep, and we restrict changes to the shown snippet.

Concretely:

• In Web/Resgrid.Web.Services/Controllers/v4/WorkflowsController.cs, locate the SaveStep action.
• Add a [ValidateAntiForgeryToken] attribute above the method (typically next to the other attributes).
• Ensure no additional imports are added, since Microsoft.AspNetCore.Mvc is already present and provides the attribute.

In general, to fix missing CSRF token validation in ASP.NET Core MVC controllers you add the [ValidateAntiForgeryToken] (or [AutoValidateAntiforgeryToken]) attribute to state-changing actions (e.g., POST/PUT/DELETE) that are invoked from browser clients and rely on cookies for authentication. The client must then include a valid anti-forgery token (via form field or header) with each such request.

For this specific issue, the minimal, non-breaking fix is to decorate the SaveCredential POST action with [ValidateAntiForgeryToken]. This keeps existing authorization and business logic intact and simply enforces that any authenticated POST to SaveCredential includes a valid CSRF token. Since the file already imports Microsoft.AspNetCore.Mvc, no additional imports are required; ValidateAntiForgeryTokenAttribute is defined in that namespace. The change is localized to the method’s attribute list, directly above public async Task<ActionResult<SaveCredentialResult>> SaveCredential(...) (around line 203–207 in Web/Resgrid.Web.Services/Controllers/v4/WorkflowsController.cs).

In general, CSRF vulnerabilities in ASP.NET Core MVC/Web API controllers are fixed by ensuring that all state‑changing HTTP endpoints that might be called from a browser validate an antiforgery token. This is typically done either by applying [ValidateAntiForgeryToken]/[AutoValidateAntiforgeryToken] globally or by decorating each sensitive POST/PUT/DELETE action with [ValidateAntiForgeryToken], and ensuring clients send the token in form fields or headers.

For this specific issue, the most targeted and non‑disruptive fix is to decorate the CancelRun action (line 323) with the antiforgery validation attribute. Since we only see this snippet and cannot assume controller‑wide attributes, we will add [ValidateAntiForgeryToken] directly above CancelRun. The file already imports Microsoft.AspNetCore.Mvc, which defines ValidateAntiForgeryTokenAttribute, so no new using directive is needed. No changes to method parameters or logic are required; existing functionality remains the same except that requests must now provide a valid antiforgery token.

Concretely:

• In Web/Resgrid.Web.Services/Controllers/v4/WorkflowsController.cs, locate the CancelRun action.
• Add [ValidateAntiForgeryToken] between the existing [Authorize(...)] attribute and the method signature (or anywhere in the attribute list).
• No additional methods or custom code are needed; we rely on the standard ASP.NET Core antiforgery filter.

In general, to fix missing CSRF validation in ASP.NET Core MVC, state-changing actions (typically POST, PUT, PATCH, DELETE) should be covered by the antiforgery system either by: (1) adding [ValidateAntiForgeryToken] (or [AutoValidateAntiforgeryToken]) on each such action, (2) adding it at the controller level, or (3) registering it as a global filter. The client must also send the antiforgery token with the request, but that is outside the scope of this snippet.

For this specific issue, the minimal, targeted fix is to decorate the ClearPending POST action with [ValidateAntiForgeryToken]. This keeps existing routing and authorization behaviour ([HttpPost("ClearPending")], [Authorize(Policy = ResgridResources.WorkflowRun_Delete)]) unchanged while adding the missing CSRF validation. ASP.NET Core’s antiforgery attributes live in Microsoft.AspNetCore.Mvc, which is already imported at the top of the file, so no new using directives or packages are needed. If other POST actions in this controller (such as CancelRun) are also intended to be called from browser contexts susceptible to CSRF, ideally they would also be annotated or covered by a broader policy, but to address the specific CodeQL finding we only change the ClearPending action signature region in Web/Resgrid.Web.Services/Controllers/v4/WorkflowsController.cs to add one attribute line directly above the method.