An endpoint starts accepting invalid data after a change. How would you investigate and fix it?

Debug broken validation in an ASP.NET Core API

Investigate an endpoint accepting invalid data or returning inconsistent validation errors.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I first identify exactly which invalid input is accepted and whether the problem is binding, request validation, business validation, or domain invariants. I reproduce the request with the real payload and check what the endpoint receives after binding. Then I inspect recent DTO, validator, controller, and error-handling changes. I also check whether invalid data already reached storage. I would tie the choice back to the contract clients consume, because small API changes can become client breakages once the endpoint is in use.

Full answer below

Practice focus

validation layers, DTO changes, model binding, error consistency, regression tests, and data cleanup

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this matters
Investigate an endpoint accepting invalid data or returning inconsistent validation errors. It matters in real backend work because clients depend on stable status codes, request and response shape, validation behavior, and compatibility after the endpoint ships. The practical angle is validation layers, DTO changes, model binding, error consistency, regression tests, and data cleanup, tied to a concrete production decision.
I first identify exactly which invalid input is accepted and whether the problem is binding, request validation, business validation, or domain invariants. I reproduce the request with the real payload and check what the endpoint receives after binding. Then I inspect recent DTO, validator, controller, and error-handling changes. I also check whether invalid data already reached storage. I would tie the choice back to the contract clients consume, because small API changes can become client breakages once the endpoint is in use.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A common example is adding a nullable field or changing a DTO so a missing value becomes a default that passes through. I would fix the rule at the right layer, return a consistent validation response, and add regression tests for malformed input and invalid business cases. The trade-off is avoiding duplicated validation while still protecting every entry point that can create data. For example, I would walk through what a client sees during success, validation failure, authorization failure, conflict, and a version change. The trade-off is that stricter contracts take more design time, but they reduce support work and accidental breaking changes later.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Fixing only frontend validation
Adding random controller if statements
Ignoring already persisted bad data
Returning inconsistent error shapes
Not adding regression tests

An endpoint starts accepting invalid data after a change. How would you investigate and fix it?

Practice focus

Answer path

Why this matters

Review signals

Follow-up prompts

Continue practice

Skill areas

Suggest an improvement