No CSRF protection mechanism currently exists in the framework. Form submissions (NGForm) and action invocations have no token mechanism, allowing cross-site form submissions to trigger authenticated actions.
Why this matters
This is a standard web security concern that adopters will ask about — particularly the WO audience evaluating ng-objects as a successor framework. Silence on the question hurts adoption.
Possible directions
Three reasonable answers:
- Built-in token mechanism. Framework injects a per-session (or per-form) token into forms; action handlers verify on submit. Most opinionated, most ergonomic, most work to build correctly.
- Documented pattern. Framework provides primitives (form metadata, header inspection) and a documented "here's how to add CSRF protection to your app" page. Lower commitment, requires user diligence.
- Hybrid. Built-in opt-in (
Application.csrfProtection(true) or per-form attribute) with documented pattern for opt-out / custom strategies.
The session-bound URL token work (#54) addresses session-stickiness of stateful URLs but is not a complete CSRF answer on its own.
M2 expectation
At minimum: a documented answer. Ideally: built-in mechanism shipping in M2.
No CSRF protection mechanism currently exists in the framework. Form submissions (
NGForm) and action invocations have no token mechanism, allowing cross-site form submissions to trigger authenticated actions.Why this matters
This is a standard web security concern that adopters will ask about — particularly the WO audience evaluating ng-objects as a successor framework. Silence on the question hurts adoption.
Possible directions
Three reasonable answers:
Application.csrfProtection(true)or per-form attribute) with documented pattern for opt-out / custom strategies.The session-bound URL token work (#54) addresses session-stickiness of stateful URLs but is not a complete CSRF answer on its own.
M2 expectation
At minimum: a documented answer. Ideally: built-in mechanism shipping in M2.