An exported Application Contract can disclose path names, parameter names, schemas, and example data. Only explicitly contracted public operations are exported; review them and restrict access to generated artifacts. Never include real APP_KEY, database passwords, PATs, OAuth client secrets, Webhook signing secrets, Authorization values, or session cookies in contract declarations. OpenAPI documentation does not enforce Auth, Authorization, validation, CSRF, or rate limiting at runtime.
Source-changing CLI commands use reviewable change plans. A plan contains safe relative targets and fingerprints, not existing file contents, private configuration values, credentials, or request data. A preview does not apply the change; non-interactive application requires --yes. Stale file and ownership checks prevent known conflicts from being silently overwritten. A Package plan is not a security sandbox: enabled Package code can execute at ordinary application boot, and package:verify deliberately executes trusted Package definitions. A Kit plan is also not a sandbox: its explicit lifecycle hooks are trusted PHP that can have effects outside the file plan. Static Kit inspection and preview do not execute entry PHP; review source before applying a Kit, and run generated Migrations and Seeders only through their separate, deliberate commands.
Package and Kit acquisition also have different explicit source boundaries. Package install accepts physical local directories and credential-free HTTPS Git repository URLs; Kit install accepts physical local directories only. Neither installer downloads or extracts ZIP archives, verifies release checksums, handles file:// sources, or authenticates private remote URLs. A Git Package preview may contact a remote and use temporary checkout storage, but must not change application Package files or activation state. A Kit install leaves the Kit disabled and does not publish its mapped application files; applying the install can still run any declared beforeInstall or afterInstall trusted hook. Review source, hooks, and generated PHP before applying. Source-path, linked-entry, casing, stale-plan, and ownership checks reduce accidental changes; they do not make malicious third-party PHP safe.
Generated SDK source also reveals the contracted API shape. It receives credentials only at runtime and does not replace server-side authentication, authorization, CSRF, or CORS. Review generated output and keep its ownership manifest with it; the generator refuses unsafe output paths and does not overwrite unknown application files.
SqueHub provides secure primitives; each application still chooses its trust boundaries and policy. Review this page together with Deployment before serving public traffic.
The View Auth, Guards, Session and Authorization guide adds presentation directives such as @auth and @can. They only decide which markup renders. A hidden button does not protect a route, controller, service, database operation, or API. Protect those boundaries with middleware and authorize()->require(...) as appropriate.
| Area | Framework behavior | Application responsibility |
|---|---|---|
| SQL | QueryBuilder binds values and validates identifiers/operators. | Preserve database constraints, avoid untrusted raw SQL structure, and authorize data access. |
| HTML | {{ }} escapes output; {!! !!} is deliberately raw. | Validate URL schemes and non-HTML contexts; never render untrusted HTML raw. |
| CSRF | Global middleware protects unsafe web requests with a session token. | Add @csrf to forms, set deliberate exclusions only for separately authenticated endpoints. |
| Sessions | ID regeneration/invalidation and cookie controls are available. | Use HTTPS, secure cookie settings, and a protected writable backend. |
| Passwords | Auth uses password hashing and optional rehash on login. | Choose identity fields, reset flows, strength policy, and rate limits. Never store plaintext passwords. |
| Remembered browser login | Opt-in Session login stores a hashed validator, rotates the browser credential on recall, and rejects stale credentials. | Offer a deliberate remember choice, use HTTPS and narrow cookie scope, and revoke other browsers when an identity is compromised or removed. See Authentication. |
| Multi-factor authentication | Opt-in TOTP and one-time recovery codes keep enrolled identities pending until proof succeeds; secrets are encrypted and attempts rate-limited. | Protect enrollment and recovery-code display, require step-up as appropriate for sensitive actions, and keep the Crypt key available for stored credentials. See MFA. |
| API tokens | Named token guards hash high-entropy personal access secrets and check expiry, revocation, and abilities. | Authorize issuance, protect the one-time raw response, use HTTPS, choose narrow abilities and expiry, and revoke compromised credentials. |
| OIDC login | Configured clients use code with PKCE, a session-bound one-time state, nonce, strict response issuer, discovery/JWKS policy, and signed ID-token validation. | Register an exact redirect URI, protect session cookies and egress, map (issuer, subject) deliberately, and qualify the chosen provider. |
| Webhooks | A SqueHub-specific signed event profile, timestamp checks, named endpoints/sources, and optional persistent receipt claims are available. | Keep signing secrets private, use HTTPS and egress rules, explicitly exclude only the receiving path from CSRF, and make business handling safe under retries. |
| Authorization | Gates and policies can require a decision. | Register abilities/policies and check every protected action; a query scope is not permission. |
| Roles and permissions | Opt-in RBAC contributes permissions beneath explicit Authorization decisions; it does not invent an administrator bypass. | Assign narrow roles and permissions, keep direct denials effective, and continue checking resource policies where context matters. |
| Rate limits | Atomic fixed-window stores and route middleware are available. | Choose keys, limits, middleware order, and shared backend for the deployment topology. |
| Inbound proxy and Host trust | Forwarded IP, protocol, and Host are ignored unless the immediate REMOTE_ADDR is configured as a trusted proxy and one forwarding profile is selected. An optional allowed-host list rejects unknown effective hosts. | List only known proxy addresses/CIDRs, configure the proxy to replace or sanitize client forwarding headers, restrict direct bypass, and set allowed public hosts for the deployment. Never use a trust-everybody range. |
| URL subdirectory mount | An explicit APP_BASE_PATH keeps application routes separate from their public URL prefix and rejects paths outside that bounded mount. | Map only public/ into the web server's subdirectory; use route()/asset() in Views rather than literal root paths. Configure Session cookie Path and a canonical public origin deliberately. |
| Browser response policy | An opt-in browser security policy can add CSP, HSTS on effective trusted HTTPS, Referrer-Policy, frame restrictions, and nosniff at the Kernel response boundary. | Review existing inline Views, host-wide HSTS effects, proxy trust, endpoint-specific headers, and Session/remember cookie scope before enabling a production profile. |
| Signed URLs | Purpose-bound, expiring named-route links authenticate their path and bounded query fields with a Crypt-derived MAC. | Deliver them over HTTPS, keep the bearer signature out of logs, and separately enforce Auth, resource policy, or one-time redemption where needed. A valid signature alone does not grant general resource access. |
| Crypt | Authenticated encryption, MAC, and token utilities use APP_KEY. | Keep keys private, plan rotation, never encrypt passwords, and handle backups. |
| Files | Storage enforces logical path containment; upload rules inspect formats. | Authorize file operations, scan/sanitize content as needed, and never execute uploaded templates. |
| Errors/logs | Production errors hide traces; logging redacts recognized secrets. | Do not put unknown secrets in free-form messages or publicly expose logs/diagnostics. |
| Agent and MCP | Optional local STDIO inspection starts with six bounded read-only capabilities; schema and review-only plans require scoped grants. Unsupported mutation capabilities cannot be enabled through config. | Keep Config/Agent.php trusted, inspect effective grants with agent:status, treat application-authored metadata as untrusted prompt content, and do not expose .env, private Storage, arbitrary shell/network/file access, or remote MCP without a separate security design. See Agent and AI integration. |
APP_DEBUG=false should be used in production. Put the web document root at public/; serving the repository root can expose source or .env as plain text. Do not commit .env, Queue payloads, session stores, Cache entries, logs, or Storage files. Workers, Redis, databases, and SMTP need their own access controls and backups. Webhook Queue and failed-job payloads may contain application data despite omitting signing credentials; protect their storage and backups. Diagnostics are aggregate and deliberately omit request bodies, credentials, tokens, and delivery payloads. See Webhooks for replay, receipt, and transport boundaries.
Trusted proxies and allowed hosts solve different problems. The proxy list identifies which immediate network senders may supply forwarding metadata; the allowed-host list identifies which effective hostnames the application accepts. Neither setting authenticates a user or authorizes a route. A malicious direct client cannot use Forwarded or X-Forwarded-* to enter a host-restricted route merely by sending those headers. A trusted proxy still needs to replace or sanitize headers it receives from clients. SqueHub rejects malformed selected forwarding data rather than promoting it to authoritative metadata, and a disallowed effective Host is a safe 400. See trusted request metadata and deployment examples.
An HTTP base path is not a filesystem containment rule. APP_BASE_PATH=/app controls request matching and generated public paths; it does not make it safe to serve the repository itself from /app/. Expose only public/ at that URL and keep source, .env, runtime Storage/, and the CLI outside the web-accessible mapping. The default Session cookie Path remains /; use a deliberate SESSION_PATH=/app for a mounted app when other same-host paths should not receive it. Explicit Cookie Paths are not rewritten. The legacy url() and App\Core\Verification::tokenUrl() helpers are not proxy- or mount-aware; compose security-sensitive absolute links from a reviewed canonical HTTPS origin and a generated public route() path. See subdirectory deployment.
Authentication, authorization, rate limiting, CSRF, and validation solve different problems. A validated email value does not prove ownership or justify automatic OIDC account linking; a signed-in user is not automatically authorized; an API token ability does not override a policy denial; a rate limit does not lock an account; a soft-delete timestamp is not an audit log. See OIDC login, API tokens, Account security, Errors, and Health for the precise boundaries.
An AI host is not an application administrator. MCP tool arguments and generated plans are untrusted, even when a local operator chose the host. The Agent capability registry checks an Application-scoped grant on every resource/tool call; a plan's fingerprint or model-generated approval text never bypasses the owning Migration, Package, Kit, or Feature Blueprint workflow. The Agent has no general shell, read_file, write_file, or outbound HTTP tool. For an exact map of supported and deliberately unsupported capabilities, see Agent and AI integration.
The SqueHub MCP connection exposes only its selected resources and tools. An AI client may have other shell, file, browser, or network tools under that client's separate permissions. Keep those permissions distinct when evaluating an AI workflow. A client's claimed name or model identity does not grant SqueHub permissions. SqueHub validates tool arguments, requires an exact allowlisted schema connection or plan operation, omits data rows, redacts recognized credential values, and bounds STDIO input and output. Application-authored route names, Package metadata, and documentation excerpts can still carry untrusted instructions or sensitive prose; output filtering cannot identify every secret embedded in that text. Review source before making it available to a host. search_docs reads installed public Markdown under Documentation/; it does not search local development records in Docs/. See MCP tools and resources for each output boundary.
Local STDIO, capability-denial, redaction, stdout-purity, and plan-only boundaries have passed Windows and native Linux tests. Official MCP SDK client interoperability was exercised on Linux. This first-party verification does not establish a remote MCP security design; see Agent and AI integration and current status.