Recommended Free Tools
Put project-specific Cursor instructions in focused .cursor/rules files, attach each rule to the files where it applies, and make one security requirement explicit: every Server Action must authenticate the caller and authorize the specific operation on the server. Cursor rules can guide code generation, but they do not enforce permissions at runtime.
Where Cursor Project Rules belong
Cursor Project Rules live under .cursor/rules and can be committed with the repository so the team shares them. They use MDC files, commonly with a .mdc extension, and metadata such as description, globs, and alwaysApply to control when instructions are included. Cursor also supports nested rules directories, which can help organize a monorepo or distinct subsystems.
As an Amazon Associate I earn from qualifying purchases.
These are distinct from Cursor User Rules, which apply to an individual user’s work rather than defining repository conventions for everyone. The older root-level .cursorrules file remains supported but is deprecated in favor of Project Rules, according to Cursor’s Project Rules documentation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use short, actionable rules with examples that match the codebase. If a rule grows to cover unrelated subjects, split it into smaller rules. Avoid setting alwaysApply: true merely because an instruction matters: reserve Always for concise guidance that should be present for every task.
#1 Best Overall
Choose a rule mode that matches its scope
| Mode | When it applies | Good fit |
|---|---|---|
| Always | Included in every context. | Brief repository-wide conventions, such as the package manager or shared TypeScript expectations. |
| Auto Attached | Included when referenced files match the rule’s configured paths. | App Router conventions for route files or security guidance for the repository’s action modules. |
| Agent Requested | The agent may select it when its description indicates relevance. | Specialized guidance for a less common subsystem; write a description that makes the applicable task clear. |
| Manual | Applied when a developer explicitly invokes the rule by name. | Optional checklists or workflows that should not be active for every related file. |
Mode names and behaviors are described in Cursor’s Project Rules documentation. Check the current Cursor interface if its labels or controls differ from those documented there.
Build rules around the repository’s actual App Router
The Next.js App Router is file-system based and uses React Server Components, Suspense, and Server Functions. The relevant conventions depend on the application’s real directory layout and installed Next.js version. Before choosing globs, inspect the project tree: a convention for app/** may not match a repository that keeps its application under src/app, and action code may be colocated with routes rather than stored in a dedicated directory.
Rank #2
The following is a starting point, not a set of canonical Cursor patterns. Adapt the paths and instructions to the project before committing them.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Repository-wide conventions
---
description: Shared conventions that apply across this repository
alwaysApply: true
---
- Use the repository's existing package manager and scripts; do not introduce a second package manager.
- Follow the TypeScript strictness and import-alias conventions already configured in the project.
- Prefer established local patterns over adding a new library or architectural convention.Keep a global rule small. Route-specific conventions, client/server boundaries, and mutation security have narrower scopes and are easier to apply reliably as separate rules.
App Router conventions
---
description: Conventions for this repository's App Router modules
globs: app/**/*.{ts,tsx}
alwaysApply: false
---
- Follow the route, layout, loading, and error-boundary patterns used in this application.
- Keep modules as Server Components unless browser-only behavior requires a Client Component.
- Add client/server boundaries deliberately and keep data fetching consistent with the surrounding route.Remove the leading space before globs in the sample if copying it; valid MDC frontmatter requires correctly formatted metadata. Replace the example path with the actual application path, such as a project-specific src/app location where appropriate. Rules should describe conventions the repository really uses rather than imposing generic Next.js preferences.
Server Action guidance
---
description: Security requirements for files that define or invoke server mutations
globs: app/**/actions.{ts,tsx}
alwaysApply: false
---
- At each Server Function entry point, establish the caller from trusted server-side authentication state.
- Authorize the specific operation on the specific record using server-verified data; never trust client-supplied identity, role, ownership, or permission claims.
- Validate and constrain every client-controlled value, including FormData and bound arguments, before using it.
- Keep privileged data access and secrets on the server; return only fields the authorized caller may receive.
- After a mutation, revalidate or redirect according to this application's data-flow design; do not perform mutation side effects during render.The action-file glob is illustrative only. If actions are exported from route files or colocated elsewhere, use patterns that actually match those modules. A security rule should reach all relevant mutation entry points, not just a directory that happens to contain some actions.
Client component boundary
---
description: Guidance for modules that run as Client Components
globs: app/**/client.{ts,tsx}
alwaysApply: false
---
- Use "use client" only where browser APIs, client-side state, or event handlers require it.
- Do not put secrets, privileged database access, or server-only credentials in client modules.
- Treat client-side checks as user-interface behavior, not as authorization.Because this example filename pattern is narrow, adapt it to how the repository identifies client components; a naming convention may not exist. Client modules are marked by the "use client" directive, but not every client component necessarily has a distinctive filename.
Why each Server Action needs its own authorization check
A Server Function is an asynchronous function that runs on the server and can be called from a client through a network request. When used for a mutation, it is commonly called a Server Action. The "use server" directive marks an async function or file exports for server execution. Next.js documentation says actions can be reached through direct POST requests; they are not callable only through the visible interface that happens to invoke them.
That changes where security belongs. A hidden button, client-side role check, import pattern, or protected route and layout may influence what a user sees, but none proves that the action itself is authorized. Next.js’s Mutating Data and Authentication guides advise verifying authentication and authorization inside every Server Function and treating actions with the security considerations of public-facing API endpoints.
Check identity, permission, and input at the action boundary
- Establish who is calling. Read the authenticated identity from trusted server-side session or authentication state. Do not use a user ID submitted by the browser as proof of identity.
- Authorize this operation on this resource. Check whether that caller may perform the requested operation on the particular record at the action entry point. Verify ownership, role, or permission from trusted server-side data instead of accepting client assertions.
- Constrain the request. Treat
FormData, bound arguments, and other client-controlled values as untrusted. Validate their shape and allowed values before using them in database queries, business logic, or side effects. - Limit what leaves the server. Keep privileged database access and secrets in server-only code, and return only the information the authorized caller needs and is entitled to see.
- Handle mutation consequences deliberately. Revalidate affected data or redirect in accordance with the application’s data flow. Avoid mutation side effects during rendering.
These are implementation recommendations, not requirements to use a particular authentication provider or validation library. The key boundary is the Server Function itself: it must make its own decision using trusted state before carrying out the mutation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What framework safeguards do—and do not—cover
Next.js’s current Server Actions configuration reference describes a default same-origin check that compares the request origin with the host, with additional trusted domains configurable through allowedOrigins for architectures such as proxies. Add only origins required by the real deployment path; a broad or wildcard allowance weakens the point of an explicit trust list. The same reference documents a default Server Action request body limit of 1 MB, which can be configured when the application has a justified need.
Configuration keys, their placement, and experimental labels can vary by Next.js version. Check the installed version’s configuration reference before copying a snippet or changing an origin or body-size setting. Same-origin checks address request-origin concerns; they do not determine whether a user may edit a record. Likewise, a body-size limit constrains request size, not the meaning or permission of submitted values.
The Next.js 15 Data Security guide also documents POST-only invocation, origin/host comparison, encrypted non-deterministic action IDs, and dead-code elimination. Those details are tied to that version’s guide, last updated September 23, 2025, and should not be presented as universal guarantees for every current or future version. In any case, encrypted or non-deterministic identifiers do not make an action private and do not replace authorization or safe handling of returned data.
Quick Recap
Review the rules and the implementation separately
- Confirm each path pattern matches the files that contain the relevant code, including any
srcprefix or colocated action modules. - Keep each rule focused, and select Always, Auto Attached, Agent Requested, or Manual according to how broadly and automatically it should apply.
- For every mutation, verify that the action identifies the caller from trusted state and authorizes that caller for the exact operation and resource.
- Check that client-controlled input is validated, privileged code stays server-side, and responses contain no unnecessary sensitive fields.
- Review origin and body-size configuration against the deployed architecture and the installed Next.js version.
- Review generated security-sensitive code and enforce authorization in application code and tests; instructions to an AI agent are not runtime controls.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
