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 makes the receiving function clean its parameter at run time, as it is entered. Runtime detectors scan for SQL injection, XSS, command injection, path traversal, LDAP injection, header injection and expression injection, and a value carrying a threat arrives unset. There is no compile-time taint tracking: the compiler only checks where 'sanitized' may be written and rejects aliasing the parameter into a local (E07930).
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. Guards enforce safe value access before use.
A05 SECURITY MISCONFIGURATION
Constrained types enforce valid configuration at construction time. For untrusted input use Type().of(value): a value that breaks the constraint gives an unset object that a guard catches, so misconfiguration cannot silently propagate. A bare constructor call asserts the value is valid, so a violation is a Panic (or E08260 when the value is a compile-time constant).
A08 DATA INTEGRITY FAILURES
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 parameters on URL and path parameters mean the receiving function scans each value on entry, so a user-provided URL or path carrying a recognised threat (path traversal, for example) arrives unset instead of being used.
See Q29 for tri-state model. See Q54 for pure functions. See Q74 for guards. 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") // === GUARDS (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 — A misspelt function name cannot be resolved, so E50001 is reported on that line. Spell the declared function name exactly. See ek9 -h E50001 for details.
Incorrect:
result <- processExternalInpt(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, everything is mutable. Rust: ownership model prevents some categories. Go: no generics until recently, no purity. Kotlin: null safety helps but open by default, no sanitization. EK9: closed types, the sanitized keyword (run-time cleaning on entry), pure functions, tri-state model, no null, constrained types, guards prevent multiple OWASP categories by design.
Keywords: language, security, safe, protect, cve, secure, vulnerability, owasp, design, prevention, attack