By the end of this session, you will be able to:

• Explain why server-side validation is mandatory, regardless of what the frontend does
• Validate request data using built-in DataAnnotations attributes
• Write richer, testable validation rules using FluentValidation
• Return consistent validation error responses in the ProblemDetails format
• Understand what sanitization is, when it applies, and how it differs from validation
• Prevent over-posting and mass assignment vulnerabilities in request DTOs

• Frontend validation is UX — it catches mistakes early and gives instant feedback, reducing round trips and frustration
• Server-side validation is security — it is the only check that cannot be bypassed by a client, a proxy, or a script
• Bypassing frontend validation is trivial — Postman, curl, and browser developer tools all allow sending arbitrary HTTP requests with no React code involved
• The backend cannot know who the caller is — it might be your React app, a mobile app, a third-party integration, or a malicious actor; all look identical at the HTTP level
• Invalid data that reaches the database is expensive to fix — constraint violations crash requests; corrupt data silently degrades the application for all users

using System.ComponentModel.DataAnnotations;

public class CreateTaskRequest
{
    [Required(ErrorMessage = "Title is required.")]
    [MaxLength(200, ErrorMessage = "Title cannot exceed 200 characters.")]
    public string Title { get; set; } = "";

    [MaxLength(2000, ErrorMessage = "Description cannot exceed 2000 characters.")]
    public string? Description { get; set; }

    [Range(1, 5, ErrorMessage = "Priority must be between 1 and 5.")]
    public int Priority { get; set; } = 1;

    public DateTime? DueDate { get; set; }
}

Attributes stack — a property can carry multiple annotations. Each rule is checked independently. All violations are collected and returned together in the 400 response body, not one at a time.

• Complex rules are readable — conditional logic (.When), cross-property checks, and chained predicates read like English sentences rather than attribute soup on a model class
• Validators are testable in isolation — a CreateTaskRequestValidator is a plain class; you can write unit tests against it without an HTTP request or a controller
• Rules live in one place — validation logic is not scattered across DTO properties, controller actions, and service methods
• Rich built-in rules — NotEmpty, MaximumLength, GreaterThan, Matches (regex), Must (custom predicate), and async variants for database checks
• Error messages are centralized — .WithMessage() at the rule level; no need to repeat error strings in attribute constructors across multiple DTOs

using FluentValidation;

public class CreateTaskRequestValidator : AbstractValidator<CreateTaskRequest>
{
    public CreateTaskRequestValidator()
    {
        RuleFor(x => x.Title)
            .NotEmpty().WithMessage("Title is required.")
            .MaximumLength(200).WithMessage("Title cannot exceed 200 characters.");

        RuleFor(x => x.Priority)
            .InclusiveBetween(1, 5)
            .WithMessage("Priority must be between 1 and 5.");

        RuleFor(x => x.DueDate)
            .GreaterThan(DateTime.UtcNow)
            .When(x => x.DueDate.HasValue)
            .WithMessage("Due date must be in the future.");
    }
}

Each RuleFor call targets one property. Rules chain with . — all chained rules apply to the same property in order. .When() makes the preceding rule conditional.

using FluentValidation;

public class UpdateTaskRequestValidator : AbstractValidator<UpdateTaskRequest>
{
    public UpdateTaskRequestValidator()
    {
        RuleFor(x => x.Title)
            .NotEmpty().WithMessage("Title is required.")
            .MaximumLength(200).WithMessage("Title cannot exceed 200 characters.")
            .Must(t => !t.Contains('<')).WithMessage("Title must not contain HTML tags.");

        RuleFor(x => x.Description)
            .MaximumLength(2000)
            .WithMessage("Description cannot exceed 2000 characters.")
            .When(x => x.Description is not null);

        RuleFor(x => x.DueDate)
            .GreaterThan(DateTime.UtcNow)
            .When(x => x.DueDate.HasValue)
            .WithMessage("Due date must be in the future.");
    }
}

Each request DTO gets its own validator class. This keeps rules separate and makes unit-testing each set of rules straightforward without coupling them to the controller.

• Validation — decide whether an input is acceptable. If not, reject it and return an error. The input never enters the system. Example: a title longer than 200 characters is rejected with a 400 response
• Sanitization — transform an input so it is safe to use in a specific context. The input is accepted but cleaned before storage or rendering. Example: HTML-encode <script> before saving user-provided description text
• The strategies are complementary — validate first to reject obviously bad inputs, then sanitize the accepted inputs before using them in a context where they could cause harm
• Context matters — the same string that is safe in a JSON response might be dangerous when rendered in HTML, inserted into a SQL query, or passed to a shell command

• Over-posting occurs when a client sends more fields than the endpoint expects. If the server maps the entire request body directly to an entity, the extra fields silently overwrite properties that should not be settable from the outside
• Classic example — a CreateUserRequest has only Name and Email, but a client sends an extra "IsAdmin": true field that maps onto the entity and elevates their own privileges
• The fix is to use dedicated request DTOs — never bind directly to an entity class in a controller action. The DTO defines exactly which fields the client is allowed to supply
• Request DTOs are the validation boundary — only properties on the DTO exist as far as model binding is concerned; any extra fields in the JSON are ignored

• Validate the extension — maintain an allowlist of permitted extensions (e.g., .jpg, .png, .pdf) and reject anything else. Never use a blocklist — attackers enumerate extensions you forgot to block
• Validate the MIME type — read the Content-Type header and compare it against the extension. A file named photo.jpg with Content-Type: application/x-executable is not a photo
• Validate the file size — set MaxRequestBodySize in Kestrel to prevent multi-GB uploads from exhausting server memory before your action code can reject them
• Never trust the filename — normalize the filename with Path.GetFileName to strip directory traversal sequences before using it in a file path
• Store outside the web root — uploaded files should not be directly accessible by URL; serve them through a controller action that enforces authorization

Add FluentValidation to the Task API and verify that the error response shape matches the ProblemDetails format from Session 05.

• Server-side validation is mandatory — the frontend can be bypassed; the server cannot. Every field the client supplies must be validated before it is used or stored
• DataAnnotations handle simple rules declaratively — attributes on DTO properties are enforced automatically by [ApiController], which returns 400 before the action runs
• FluentValidation handles complex rules as code — conditional rules, cross-property checks, and custom predicates live in dedicated, unit-testable validator classes
• Validation rejects; sanitization cleans — encode HTML before rendering, use EF Core parameterized queries to prevent SQL injection, and use dedicated DTOs to prevent over-posting
• Error responses follow the ProblemDetails format — the errors dictionary groups messages by field name, keeping the API consistent with the error handling established in Session 05

Session 13 — Authentication Theory & JWT

• Sessions 9–12 built a fully persisted, shaped, and validated data layer — the API now enforces what data it accepts. Session 13 introduces authentication: enforcing who is allowed to make requests at all
• You will learn how stateless authentication works with JSON Web Tokens (JWT) — what they contain, how they are signed, and how the server verifies them without a session store
• The Task API will gain a /auth/login endpoint that issues a signed JWT, and all task endpoints will be protected with [Authorize]
• The validators you wrote today become the first line of defence on the login endpoint — rejecting malformed credentials before any authentication logic runs

Add full FluentValidation coverage to the Task Manager API and verify consistent error responses.

What to build:

• Write CreateTaskRequestValidator and UpdateTaskRequestValidator covering: non-empty title, max 200 characters, no HTML tags in title, and due date in the future when provided
• Register both validators and AddFluentValidationAutoValidation in Program.cs — remove any overlapping DataAnnotation attributes from the DTOs to avoid duplicate error messages
• Confirm the task creation and update endpoints return a 400 with a well-formed ValidationProblemDetails body when any rule is violated

Acceptance criteria:

• Sending an empty title to POST /api/tasks returns 400 with errors.Title containing the expected message
• Sending a title of 201 characters returns 400 with a max-length message
• Sending a title containing <script> returns 400 with the no-HTML-tags message
• Sending a past due date returns 400 with the future-date message
• Sending a valid request returns 201 with the created task — no validation errors