Injection and output handling
6 challengesEncode untrusted HTML, stop CRLF injection, and build dynamic SQL fragments from trusted outputs instead of raw input.
Hands-on application security in C#
C# secure coding exercises that attack your fix
Start from C# that is functionally correct and quietly exploitable. Patch the trust boundary, keep the feature working, and submit against real attack payloads across 20 focused challenges.
Five free previews. Authorized payloads. Nothing to install.
- security exercises
- 20
- free previews
- 5
- test suites
- 2
Normal tests cannot see the hole
Make the feature work and the exploit fail
Vulnerable code often passes every happy-path test. The difference appears only when an attacker supplies a traversal path, a private host, a forged log line, or an identifier shaped to escape the place you put it.
Katabench runs the ordinary suite and a separate adversarial suite. Blocking every input breaks the feature and fails. Preserving the feature while leaving one bypass open also fails. The defense has to hold both constraints at once.
Start with the OWASP Top 10 through a C# lens or read how the two suites are graded.
The adversarial suite
../../etc/passwd
path traversal
✓ denied
evil-example.com
suffix confusion
✓ rejected
http://169.254.169.254/
SSRF
✓ blocked
ada\n[INFO] admin granted
log forging
✓ escaped
✓ 6 / 6 functional | ✓ 4 / 4 exploits blocked
Five secure-coding skill families
Practice the boundary, not the security slogan
Each family repeats a code-level failure mode with different inputs and business behavior, so the defensive move becomes something you recognize before review finds it.
URL, host, and origin trust
5 challengesDefend SSRF boundaries, CORS allowlists, redirect targets, link schemes, and hostname checks against inputs made to look almost safe.
Files and uploads
3 challengesKeep paths inside their root, reduce filenames to one safe segment, and accept only the content types the feature actually supports.
Input and business-rule boundaries
4 challengesBlock mass assignment, integer overflow, negative money flows, and resource-exhausting values without disabling the valid feature.
Information disclosure
2 challengesReturn uniform account messages and safe errors so internal details and record existence do not leak through an otherwise working endpoint.
Free C# security exercises
Fix five vulnerabilities in the browser
Open a preview, inspect the working-but-vulnerable starter, and harden it until normal inputs still pass and the exploit payloads bounce. No project download or SDK setup is required.
- 01 Easy
Comment Renderer (HTML Injection)
Fix a stored-XSS hole in a comment renderer without breaking its output.
Open this challenge → - 02 Easy
Filename Sanitizer
Reduce an uploaded filename to a safe, single path segment.
Open this challenge → - 03 Easy
Log Forging (CRLF)
Stop user input from forging extra log lines with embedded newlines.
Open this challenge → - 04 Easy
Mass Assignment Guard
Decide which submitted fields may be applied to a record using an allowlist, not a blocklist.
Open this challenge → - 05 Medium
Block Private Hosts (SSRF)
Reject internal hosts so a user-supplied URL cannot make the server call itself or its neighbors.
Open this challenge →
The defensive coding loop
Find the trust boundary, repair it, prove it
01
Start from vulnerable code
The feature already works for normal input. Read the C# and find the trust boundary that lets a hostile value change what the program does.
02
Make the narrowest safe fix
Encode, validate, normalize, or allowlist at the right boundary. Removing the feature or rejecting every input does not count as a defense.
03
Face the exploit suite
Submit against ordinary behavior tests and adversarial payloads. The solution passes only when the feature survives and the attack fails.
The goal is defensive judgment, not exploit tooling. Every payload is part of the authored exercise and runs only against your submitted code inside Katabench's isolated sandbox.
C# secure coding FAQ
Before you face the first payload
What are C# secure coding exercises?
They are small C# programs that behave correctly for normal input and fail at a security boundary. You repair the vulnerability, then functional tests and adversarial payloads verify that the feature still works and the exploit no longer does.
Are these ASP.NET Core security exercises?
Many scenarios come from ASP.NET Core and API work, including HTML output, CORS origins, redirects, uploaded files, mass assignment, SQL fragments, SSRF, and safe error responses. Each exercise isolates the vulnerable C# boundary so the feedback stays focused.
Do the exercises cover the OWASP Top 10?
They practice code-level failure modes related to several OWASP categories, including injection, SSRF, security misconfiguration, access-control boundaries, and data-integrity mistakes. They are not an OWASP certification course or a one-to-one checklist of every category.
Are the secure coding challenges free?
Five challenges are free previews: HTML injection, filename sanitization, log forging, mass assignment, and SSRF host blocking. Katabench Pro unlocks all 20 secure-coding exercises and unlimited submissions.
Do I attack a live application?
No. These are defensive coding exercises inside Katabench's isolated sandbox. You modify the provided C# and submit it against authorized test payloads. The exercises never ask you to probe another system.
Can I reveal a secure reference solution?
Yes. After trying the challenge, you can reveal a correct reference solution, inspect where it validates or encodes the input, then reset and implement the defense again. Daily reveal limits depend on your plan.
Keep the feature. Break the exploit.
Start with the free HTML-injection challenge and let the functional plus adversarial suites tell you when the defense actually holds.
Try an XSS challenge free