How does EK9 prevent common security vulnerabilities?
← Security and Sanitization · Ref: Q268
EK9 prevents entire classes of vulnerabilities through language design decisions, not just libraries or best practices. Several OWASP top 10 categories are addressed at the language level.
A01 BROKEN ACCESS CONTROL
Types are closed by default (no 'as open' means cannot extend). There is no reflection API to bypass access modifiers. Private fields and methods cannot be accessed externally.
A03 INJECTION
The 'sanitized' keyword tracks tainted input at compile time. Seven runtime detectors covering 1,300+ patterns detect SQL injection, XSS, command injection, path traversal, LDAP injection, header injection, and expression injection. The compiler enforces the copy constructor pattern for processing sanitized data.
A04 INSECURE DESIGN
Pure functions prevent uncontrolled side effects. The tri-state model (absent/unset/set) eliminates null pointer exceptions. No break, continue, or return statements prevents control flow bugs. Guard expressions enforce safe value access before use.
A05 SECURITY MISCONFIGURATION
Constrained types enforce valid configuration at construction time. Invalid values produce unset objects that guards catch, making misconfiguration impossible to silently propagate.
A08 DATA INTEGRITY FAILURES
Immutability by default protects data. Pure functions cannot use mutation operators (+=, -=, :=:, :~:, :^:). The :=: copy, :~: merge, and :^: replace operators have defined semantics preventing accidental data corruption.
A10 SERVER-SIDE REQUEST FORGERY
Sanitized parameter tracking on URL and path parameters ensures that user-provided URLs cannot be used without going through the defensive copy pattern.
See Q29 for tri-state model. See Q54 for pure functions. See Q74 for guard expressions. See Q101 for closed types. See Q144 for no break/continue/return. See Q215 for sanitized parameters. See Q216 for threat detection. See Q218 for security best practices. See Q257 for constrained types. See Q270 for supply chain security. See Q272 for defense in depth.
Example
defines module qa.security.owasp defines function // Pure function prevents side effects (A04) validateConfig() as pure -> configValue as String <- valid as Boolean: configValue? // Sanitized parameter prevents injection (A03) processExternalInput() as pure -> input as sanitized String <- result as String? // Copy constructor — defensive copy safeCopy <- String(input) result: "Processed: " + safeCopy defines program OwaspPreventionDemo() stdout <- Stdout() // === CLOSED TYPES (A01) === stdout.println("A01: Types are closed by default") stdout.println(" No reflection API to bypass access") // === INJECTION PREVENTION (A03) === userInput <- "external data" result <- processExternalInput(userInput) if result? stdout.println("A03: " + result) // === NO NULL (A04) === name <- String() if name? stdout.println("Has value") else stdout.println("A04: Unset detected safely, no null pointer") // === GUARD EXPRESSIONS (A04) === if valid <- validateConfig("production") stdout.println("A04: Config validated via guard: " + $valid) // === IMMUTABILITY (A08) === stdout.println("A08: Pure functions prevent mutation operators") stdout.println("EK9 prevents OWASP categories by design")
Common mistakes
E50001 — Renaming the variable means later references to 'result' become unresolved, triggering E50001. Variable names must be consistent. See ek9 -h E50001 for details.
Incorrect:
resultXYZ <- processExternalInput(userInput)
Correct:
result <- processExternalInput(userInput)
E08120 — In a pure function, the mutation operator += is forbidden. Use reassignment with : to create a new value instead. See ek9 -h E08120 for details.
Incorrect:
result += safeCopy
Correct:
result: "Processed: " + safeCopy
Other ways to ask this
- How does EK9 address the OWASP top 10?
- What security vulnerabilities does EK9 prevent by design?
- How does EK9 language design prevent attacks?
Coming from another language?
Java: open by default, reflection bypasses access control, relies on OWASP libraries, NullPointerException everywhere. Python: no access control enforcement, no compile-time taint tracking, everything is mutable. Rust: ownership model prevents some categories, no taint tracking. Go: no generics until recently, no taint tracking, no purity. Kotlin: null safety helps but open by default, no sanitization. EK9: closed types, sanitized keyword, pure functions, tri-state model, no null, constrained types, guard expressions prevent multiple OWASP categories by design.
Keywords: cve, protect, safe, security, language, attack, prevention, design, owasp, vulnerability, secure