Subscribe

Pillar

Application Security

Application security is what happens in your code before the request becomes someone else’s problem. The failures that matter here are boring and old: output that was never encoded, a query that trusted a parameter, a session that lived too long.

Questions about Application Security

What does SecureCoding mean by application security?

Controls you implement in the service you ship: encoding, authorization checks, cookie flags, how you talk to the database. It is not a scanner report and it is not a WAF rule you hope will catch the miss. If the sink is in your handler, the fix is in your handler.

What is on the XSS defenses list?

Libraries and platform locks for one job: stop a string from becoming HTML or script. Text encoders such as he and the OWASP Java Encoder, HTML sanitizers such as DOMPurify and sanitize-html, then browser locks such as Trusted Types and CSP. We put encode-first tools on the left of that list and enforcement on the right.

Why start with XSS and not injection or IDOR?

XSS is the place we already have a repeatable way to judge tools: did they encode the sink, or did they ask you to sanitize the whole document and hope. Injection and IDOR are just as important. We wrote the long guides first. The shortlists come when we can score them the same way.

Is a WAF an application-security control?

A WAF can buy you time. It is not a substitute for encoding the response or checking the object id. We keep WAF conversation under network security when that list exists. AppSec lists stay on what the application itself can guarantee.

Where should I read next?

Open XSS defenses if you want the shortlist. The CSRF guide, the IDOR guide, and the OWASP secure coding checklist are on the blog if you want the longer argument before a list exists.