Initial Commit

Author: Jeymz

.github/copilot-instructions.md

@@ -0,0 +1,103 @@
+# 🤖 Copilot Secure Defaults for Java, Node.js, and C# Projects
+
+These instructions guide GitHub Copilot to suggest secure, intentional code patterns for Java, Node.js, and C# development — especially in enterprise or team settings. Prioritize clarity, validation, and the principle of least surprise.
+
+---
+
+## 🔐 1. Secure by Default
+
+- Sanitize and escape all user input (prevent XSS) — never render raw data to the page.
+- Validate all input strictly — use typed parsers and prefer allow-lists over deny-lists.
+- Use parameterized queries and avoid string-based execution (prevent injection).
+- Never store secrets in code or env files — use a secure vault (e.g. CyberArk Conjur, Azure Key Vault).
+- Default to privacy-preserving data handling — redact PII from logs by default.
+
+---
+
+## 🧩 2. Language-Specific Secure Patterns
+
+### ☕ Java
+
+- Use prepared statements with `?` placeholders in JDBC — never concat SQL strings.
+- Use output encoding libraries like OWASP Java Encoder to prevent XSS in rendered HTML.
+- Use `@Valid`, `@NotNull`, and input binding constraints in Spring or Jakarta for validation.
+- Avoid `Runtime.exec()` or `ProcessBuilder` with unsanitized input — prefer safe APIs.
+- Default to OWASP Secure Coding Practices — https://owasp.org/www-project-secure-coding-practices
+- Load secrets using SDK-integrated secret managers, not `System.getenv()` or `.properties` files.
+- Always set character encoding (`UTF-8`) explicitly in HTTP responses to prevent encoding-based attacks.
+- Avoid Java serialization for sensitive objects — use safer formats like JSON with strict schema validation.
+- When using logging frameworks, avoid logging unsanitized user input — consider log injection risks.
+
+### 🟩 Node.js
+
+- Use JSON Schema validation for all structured input — prefer libraries like `ajv` or `zod`.
+- Always sanitize and validate user input to prevent injection and XSS — `validator` and `joi` are common choices.
+- Use parameterized queries with database clients (e.g. `pg`, `mongoose`) — never concat SQL or query strings.
+- Default to using `helmet` in Express to set secure HTTP headers.
+- Use `dotenv` only in local dev — use secret managers (e.g. AWS Secrets Manager, Azure Key Vault) in prod.
+- Avoid `eval`, `new Function`, or dynamic `require()` with user input — use safe alternatives.
+
+### 🟦 C#
+
+- Use parameterized queries with ADO.NET or Entity Framework to prevent SQL injection.
+- Use `System.Text.Encodings.Web` for safe output encoding in Razor views and APIs (prevent XSS).
+- Apply `[ValidateAntiForgeryToken]` in ASP.NET MVC to prevent CSRF attacks.
+- Use `DataAnnotations` (e.g. `[Required]`, `[StringLength]`) for input validation on models.
+- Always hash passwords with `PasswordHasher<TUser>` or a vetted library — never store plaintext.
+- Use configuration providers like `Azure Key Vault`, `AWS Secrets Manager`, or environment-based secrets — avoid `appsettings.json` for secrets.
+
+---
+
+## 🚫 3. Do Not Suggest
+
+### Java
+
+- Do not suggest inline SQL string concatenation — always use prepared statements with placeholders.
+- Do not suggest use of `Runtime.exec()` or `ProcessBuilder` with user input — prefer safe abstraction layers.
+- Do not suggest logging sensitive data (e.g. passwords, tokens, session IDs) — log redacted metadata instead.
+- Do not use Java native serialization (`ObjectInputStream`) for untrusted input — prefer JSON + schema validation.
+- Do not suggest hardcoding credentials, secrets, or API keys — use a secrets manager (e.g. Conjur, Key Vault).
+- Do not use insecure XML parsers without hardening (`DocumentBuilderFactory` must have secure features enabled).
+- Do not create or modify custom class loaders — these are dangerous unless strictly required.
+
+### Node.js
+
+- Do not suggest `eval`, `new Function`, or dynamic `require()` — these are unsafe unless strictly controlled.
+- Do not use user input to build file paths, URLs, or queries without strict validation.
+- Do not expose `process.env` directly to client-side code — use secure server boundaries.
+- Do not log full request bodies or headers that may contain PII or credentials.
+- Do not hardcode secrets or API keys — never commit `.env` or use `.env` in production containers.
+- Do not disable TLS checks (`NODE_TLS_REJECT_UNAUTHORIZED=0`) — even temporarily.
+
+### C#
+
+- Do not suggest string concatenation in SQL queries — use parameterized commands.
+- Do not use `Eval`, `CodeDom`, or dynamic LINQ construction with user input.
+- Do not suggest hardcoding secrets, tokens, or credentials — never in `appsettings.json`.
+- Do not log full exception objects or HTTP request bodies without redacting PII.
+- Do not disable certificate validation (`ServerCertificateValidationCallback = delegate { return true; }`) in production.
+
+---
+
+## 🧠 4. AI-Generated Code Safety
+
+- Verify all AI-suggested package names against official repositories to prevent supply chain attacks.
+- Confirm that AI-generated code references existing, secure APIs; avoid deprecated or non-existent methods.
+- Ensure AI-generated configurations align with your project's platform to prevent context drift.
+- Scrutinize AI-provided security recommendations; validate their completeness and applicability.
+- Cross-check any AI-cited references (e.g., CVEs, RFCs) for authenticity to avoid misinformation.
+- Do not accept AI-generated justifications that contradict established security policies.
+
+---
+
+## 💡 Developer Tips
+
+- If you’re working with input, assume it’s hostile — validate and escape it.
+- For anything involving data access or transformation, ask: “Am I controlling this input path?”
+- If you’re about to use a string to build a query, URL, or command — pause. There’s probably a safer API.
+- Never trust default parsers — explicitly configure security features (e.g. disable DTDs in XML).
+- If something seems “too easy” with secrets or file I/O — it’s probably unsafe.
+- Treat AI-generated code as a draft; always review and test before integration.
+- Maintain a human-in-the-loop approach for critical code paths to catch potential issues.
+- Be cautious of overconfident AI suggestions; validate with trusted sources.
+- Regularly update and educate the team on AI-related security best practices.

.github/prompts/assess-logging.prompt.md

@@ -0,0 +1,19 @@
+# 🕵️ Prompt: Logging & Sensitive Data Exposure Audit
+
+You are reviewing application code for **unsafe logging practices**, **PII exposure**, and **improper log hygiene**.
+
+Identify any of the following issues:
+
+- Logging of sensitive information (e.g. passwords, tokens, API keys, session IDs)
+- Unfiltered logs that include full request/response bodies, headers, or user-submitted data
+- Logging of stack traces or exceptions without redaction or sanitization
+- Console or print statements left in production logic
+- Logs that include internal system paths, configurations, or database queries
+- Use of insecure transports for logs (e.g. writing logs to public cloud buckets without access control)
+
+Also check for:
+
+- Missing structured log formats (JSON, ECS, etc.)
+- Lack of logging levels or misuse of `debug`, `info`, `warn`, `error`
+
+Provide refactor suggestions for redacting or excluding sensitive data. Recommend structured logging libraries or filters, and remind developers to align with least-privilege and data minimization principles.

.github/prompts/check-access-controls.prompt.md

@@ -0,0 +1,16 @@
+# 🔒 Prompt: Access Control & Authorization Review
+
+You are auditing this codebase for **authorization and access control weaknesses**.
+
+Focus on identifying:
+
+- Missing or weak role-based access control (RBAC) or attribute-based access control (ABAC) enforcement
+- Direct access to protected routes, actions, or data without permission checks
+- Business logic that bypasses access validation (e.g. trusting client-side flags or roles)
+- Use of hardcoded role or permission strings without central enforcement
+- Functions exposed via APIs that should require authentication but don’t
+- Lack of contextual access checks (e.g. ensuring users can only access their own records)
+
+If applicable, recommend use of secure middleware, centralized auth policies, and consistent permission enforcement patterns.
+
+Highlight both missing controls and inconsistently applied ones. Annotate with comments and suggest safer refactors.

.github/prompts/check-for-secrets.prompt.md

@@ -0,0 +1,13 @@
+# 🔐 Prompt: Hardcoded Secrets & Credential Audit
+
+Act as a secure code reviewer analyzing this file for **hardcoded secrets**, API keys, tokens, credentials, or other sensitive information.
+
+Flag any of the following patterns:
+
+- API keys, access tokens, client secrets, or passwords embedded as string literals
+- Usage of `process.env` in frontend code or without proper runtime protection
+- Sensitive values written to `.env`, `.properties`, or `appsettings.json` files without secret management
+- OAuth tokens, JWTs, or HMAC secrets stored or logged in plaintext
+- Secrets stored in comments, JSON blobs, test configs, or logs
+
+Highlight these with comments or suggested changes. Recommend usage of a secure vault (e.g. Azure Key Vault, AWS Secrets Manager, CyberArk Conjur) and explain the risk of each finding.

.github/prompts/check-for-unvalidated-genai-acceptances.prompt.md

@@ -0,0 +1,19 @@
+# 🤖 Prompt: Unvalidated GenAI Code Acceptance Audit
+
+You are reviewing code for signs that **AI-generated content** (e.g. from GitHub Copilot, ChatGPT, CodeWhisperer) has been accepted without validation, testing, or verification.
+
+Look for and flag the following:
+
+- Dependencies or packages that do not exist in official registries (possible hallucinated packages)
+- Calls to non-existent, deprecated, or undocumented API methods
+- Configuration code that does not match the project’s infrastructure (e.g. Azure config in AWS projects)
+- Use of placeholder, ambiguous, or overly generic variable/method names (e.g. `doTask()`, `handleThing()`)
+- Comments or TODOs referencing AI use without follow-up verification
+
+Also check for:
+
+- Lack of test coverage or validation for recently added logic
+- Sudden style or structure shifts that may indicate unreviewed AI insertion
+- No accompanying documentation or context for added code
+
+Provide suggestions for verifying third-party resources, validating logic, and encouraging human-in-the-loop code review. Include annotations where risk or uncertainty is high.

.github/prompts/review-auth-flows.prompt.md

@@ -0,0 +1,21 @@
+# 🧪 Prompt: Authentication Flow Review
+
+You are performing a security review of the application’s **authentication logic and flow handling**.
+
+Look for the following common risks:
+
+- Incomplete or improperly enforced authentication on protected routes or resources
+- Weak or non-expiring session tokens (e.g. JWTs with long-lived expirations or missing `exp`)
+- Missing or broken CSRF protections (check for missing `SameSite`, CSRF tokens in forms)
+- Use of insecure login flows (e.g. no rate limiting, no multi-factor enforcement)
+- Tokens or session identifiers exposed via logs, URLs, or frontend JavaScript
+- Direct use of user-supplied credentials in downstream API requests without validation
+
+Check for secure practices like:
+
+- Short-lived tokens + refresh workflows
+- Server-side session storage with expiration
+- Secure cookie flags (`HttpOnly`, `Secure`, `SameSite=Strict`)
+- Use of well-tested identity providers or auth frameworks
+
+Recommend mitigations for any insecure implementations you identify.

.github/prompts/scan-for-insecure-apis.prompt.md

@@ -0,0 +1,20 @@
+# ⚠️ Prompt: Insecure or Deprecated API Usage Scan
+
+Act as a secure code auditor. Your goal is to identify any usage of **insecure, deprecated, or high-risk APIs** that may introduce vulnerabilities or future instability.
+
+Look for and flag the following patterns:
+
+- Use of deprecated cryptographic functions (e.g. MD5, SHA1, `crypto.createCipher`, `System.Security.Cryptography.SHA1CryptoServiceProvider`)
+- Legacy input/output APIs that lack sanitization or encoding features
+- Insecure deserialization functions (e.g. `eval`, `JSON.parse` on external input, `ObjectInputStream`, `BinaryFormatter`)
+- Unsafe file access or shell execution APIs (`fs.readFileSync` on user input, `Runtime.exec`, `ProcessBuilder`, `child_process.exec`)
+- Unverified third-party libraries or packages not pinned to versions
+- APIs that allow insecure HTTP communication (e.g. `http.get`, `fetch` without TLS, `WebClient` without `UseHttps`)
+
+Explain:
+
+- Why the API is dangerous
+- What safer alternative is recommended
+- When/if it’s okay to use with proper mitigation
+
+Provide annotations or refactor suggestions where applicable.

.github/prompts/validate-input-handling.prompt.md

@@ -0,0 +1,21 @@
+# 🛡️ Prompt: Input Validation & Sanitization Audit
+
+You are reviewing code for unsafe or missing input validation. Your task is to identify all potential risks related to untrusted user input.
+
+Flag any of the following:
+
+- No use of structured input validation libraries (e.g. `Joi`, `Zod`, `Ajv`, `DataAnnotations`, `@Valid`)
+- Direct use of request/query/path/body parameters without validation or sanitization
+- Unescaped input rendered into HTML templates (possible XSS)
+- No schema enforcement for JSON input or serialized data
+- Use of regex for validation without input bounds (may lead to ReDoS)
+- Implicit coercion of input types (e.g. treating string as number or boolean without validation)
+
+Recommend:
+
+- Strict, schema-based input validation
+- HTML/context-aware encoding of dynamic output
+- Safe handling of nested objects, arrays, and dynamic keys
+- Input length and character whitelisting where appropriate
+
+Provide suggested fixes and explanations to help developers understand *why* these patterns are dangerous.

.github/workflows/markdownlint.yml

@@ -0,0 +1,28 @@
+name: Markdown Lint
+
+on:
+  pull_request:
+    branches:
+      - main
+        
+
+jobs:
+  markdown-lint:
+    runs-on: [Linux]
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v3
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: '18.x'
+
+      - name: Clear npm cache
+        run: npm cache clean --force
+
+      - name: Install markdownlint-cli
+        run: npm install
+
+      - name: Run markdownlint
+        run: npm run lint

.gitignore

@@ -0,0 +1 @@
+node_modules