Every Mesrai rule, in one place

Configure your application not to display detailed error messages (stack traces, PHP warnings) to end users in production. Instead, log errors for developers and show a generic message to users.

Avoid hard‐coding credentials or sensitive information (like DB passwords, API tokens or secret keys) directly in your code. Use separate configuration files or environment variables to manage these values securely.

Ensure that all caught exceptions are either logged or handled properly. Empty catch blocks are not allowed.

Avoid passing untrusted values to include/require statements. If you need to include files based on external input, strictly validate that input (for example, using a whitelist of valid filenames).

Check for empty code blocks (such as `if` or `loop` structures) that do not contain any statements. If an empty block is present, ensure it includes a comment explaining its purpose.

Never write Protected Health Information (PHI/ePHI) to logs. Redact fields like name, SSN, MRN, DOB, address, diagnoses, and lab results; store only non-identifying metadata and a stable request trace id. If logging is required for troubleshooting, replace values with consistent tokens and record access separately in the audit log.

Check if React components are defined inside other components. Nested components are recreated on every render, causing unnecessary re-renders. Suggest moving them outside the parent component.

Starting a route template with '/' in ASP.NET makes it absolute, ignoring controller-level routes and potentially breaking expected routing behavior.

Detect occurrences of the 'with' statement. This construct is banned in strict mode due to unpredictable behavior and makes debugging harder.

Every package must have a package comment, and each exported identifier must have a comment starting with the identifier name and a full-sentence summary.

All public modules, classes, and functions must include a docstring immediately after the definition, using PEP 257 conventions (one-line summary + optional sections like Args, Returns, Raises).

Identify functions that raise exceptions but do not document them in docstrings. Missing exception documentation makes it difficult to understand failure cases. Suggest adding an `:raises` section in the docstring.

If the change is risky or user-facing, describe the feature flag, rollout plan (stages/segments), monitoring signals, and a clear rollback procedure.

When a function is unsafe, may panic, or returns Result, include sections # Safety, # Panics, and/or error conditions in the docs.

Never compare the address of a variable to nil (e.g., `&x == nil`). To check if a pointer is nil, compare the pointer itself to nil. The address of a variable (`&x`) will always be non-nil if `x` exists.

Every goroutine you start should be managed. Avoid launching "fire-and-forget" goroutines that run indefinitely or without any synchronization. Provide a way to stop goroutines (using a cancel context or done channel) and/or track them (e.g., with sync.WaitGroup) to prevent leaks.

Reserve `panic` for unrecoverable situations (like invariant violations or truly fatal errors). For expected error conditions (file not found, invalid input, etc.), return an `error` to the caller instead of panicking.

Data subject export endpoints must whitelist fields and redact internal notes, tokens, and third-party IDs. Generate machine-readable output and log the lawful basis for the export.

On every create/read/update/delete of CHD or tokens, write a structured audit event (who, what, when, result) without full PAN, including only pan_last4. Persist to an append-only/immutable sink. (PCI DSS 4.0 Req. 10)

Every security-relevant action must append to an immutable, append-only audit log with fields: timestamp (UTC ISO8601), actor.user_id, actor.role, action, resource.id, result, trace_id, ip, user_agent. Logs must be signed or stored in WORM/immutable storage and forwarded to a SIEM.

Ensure that CSRF protection is enforced. Disabling CSRF protection allows malicious sites to execute unauthorized actions on behalf of authenticated users.

When sending session or other sensitive cookies, always enable the HttpOnly and Secure flags (and consider SameSite). HttpOnly prevents JavaScript access, and Secure ensures the cookie is only sent over HTTPS.

Use AES-GCM with keys from KMS to encrypt sensitive columns (e.g., SSN) before saving; store nonce and auth tag; never rely solely on disk encryption.

Encrypt sensitive columns (e.g., email, phone) with managed keys; ensure DB connection enforces TLS. Store only ciphertext; compare via deterministic token/hashes when needed. (GDPR Art. 32)