Skip to content

Security and Authentication

Precious Lyson edited this page Nov 11, 2026 · 1 revision

Security and Authentication

Security

Machinjiri provides security-related building blocks; the application must still choose safe policies, configure secrets, and enforce authorization. Follow this page as a checklist, not as a security certification.

Validate input and authorize actions

Validate all input on the server at the boundary where it enters the application. Validation answers whether data has an acceptable shape; authorization answers whether the current user may perform the requested action. Do both for protected operations.

AbstractController exposes validation-related helpers, and the framework includes FormRequest, FormValidator, FormValidatorExtended, and RuleBuilder. Check supported rules and error handling in the version you installed. Do not trust hidden form fields, client-side checks, or route parameters.

CSRF protection

The framework includes CSRFToken and controller support such as csrfField(). For state-changing browser forms:

  1. Render the CSRF field/token using the app's configured helper.
  2. Validate it on the server before performing the action.
  3. Do not exempt a route unless there is a specific, reviewed reason (for example, an API endpoint authenticated with a separate mechanism).
  4. Use secure cookie settings and HTTPS in production.

Consult your generated app's middleware and view examples to see where CSRF validation is wired. Merely rendering a token does not protect an endpoint unless the submitted value is validated.

Password storage

Use a password-hashing API rather than reversible encryption or plain hashes. The security namespace includes a Hasher interface and implementation with make(), verify(), verifyAndRehash(), and rehash checks. Configure its algorithm and work factor using the API available in your installed release.

Never log passwords, authentication tokens, or reset links. Protect account recovery and authentication endpoints against enumeration, brute force, and session fixation.

Authentication versus authorization

Authentication components include guards, providers, sessions, tokens, and OAuth integration. Authentication establishes an identity; authorization decides what that identity may do. Apply authorization checks to each sensitive resource/action, including APIs and background jobs.

Do not assume the presence of a class means that a guard, provider, or middleware is configured in your app. Review application service-provider registration and route middleware wiring.

Secrets and encryption

  • Store secrets outside source control and rotate exposed credentials.
  • Use authenticated encryption APIs and retain required nonce/IV/tag data correctly.
  • Do not invent custom cryptography or store private keys in the repository.
  • Set debug mode off in production and protect logs/backups.
  • Use HTTPS for authenticated and sensitive traffic.

Machinjiri includes encryption and token utilities. Their configuration and token-validation guarantees depend on the selected API; read its implementation and test expected failure cases before using it for security-critical data.

SQL and output safety

  • Use query-builder parameter bindings for values.
  • Never treat SQL identifiers as safe just because values are bound; allow-list dynamic column/table names.
  • Escape HTML output in views using the escaped {{ ... }} syntax.
  • Avoid returning stack traces or internal exception details to clients.

Security review before release

  • Production secrets are injected through a secure environment/secrets manager.
  • Debug output is disabled.
  • Every state-changing browser route has effective CSRF validation.
  • Authentication and authorization are applied to all protected routes.
  • Passwords use an approved password hasher.
  • User-controlled SQL values are parameterized.
  • File uploads are size/type checked and stored safely.
  • Cookies and sessions use production-safe settings over HTTPS.
  • Dependency and server updates are reviewed.

Report suspected framework vulnerabilities through the repository's security policy, not in a public issue.

Clone this wiki locally