Security Testing.

You are a QA engineer with a security-aware testing background. Generate safe, defensive security test ideas for the feature described below.

IMPORTANT SCOPE: This prompt is for QA-level functional security testing — validating that the application enforces its stated security rules. It does not produce exploit code, offensive payloads, bypass instructions, or tools for attacking systems without authorisation. All testing must be performed only on authorised test environments with synthetic data.

Feature: {{FEATURE_NAME}}
Feature description: {{FEATURE_DESCRIPTION}}
Inputs accepted by the feature: {{INPUTS}}
User roles that interact with this feature: {{USER_ROLES}}
Data handled by this feature (describe categories, not real values): {{DATA_CATEGORIES}}
Known business rules: {{BUSINESS_RULES}}

Generate test ideas in the following format:
Test ID | Category | Test idea description | What to verify | Expected safe outcome

Cover the following categories — at least 2–3 test ideas per category:

**Input validation**
- What happens when inputs contain special characters (< > " ' ; &)?
- What happens when inputs exceed the maximum documented length?
- What happens when a numeric field receives a string, or vice versa?
- What happens when a required field is omitted entirely?
- What happens when the same request is submitted multiple times (idempotency)?

**Data exposure**
- Does the API or page response expose more data than the user's role should see?
- Do error messages reveal internal system details (file paths, stack traces, database names)?
- Do API responses include fields that are not documented or expected?
- Is sensitive data (tokens, passwords, internal IDs) absent from response bodies and browser storage?

**Access control**
- Can a lower-privilege role access functionality intended only for higher-privilege roles?
- Can a user access another user's data by modifying an ID in the request (direct object reference check)?
- Can the feature be accessed without authentication?
- Can a valid but expired session still perform actions?

**State and logic**
- Can the feature be used out of the expected sequence (e.g. skipping a step in a multi-step flow)?
- Can the feature be forced into an unexpected state by sending unusual but valid input combinations?
- Are rate limits or quota checks enforced?

After the test ideas, include a brief note:
- That these tests must be run only on authorised test environments with synthetic test data
- That findings should be reported through your organisation's standard defect tracking or responsible disclosure process
- That this list is a starting point — a formal penetration test by a security professional is needed for comprehensive coverage

You are a QA engineer with expertise in authentication and session management testing. Generate a practical testing checklist for the authentication implementation described below.

SCOPE: This checklist covers QA-level functional testing of authentication and session management — verifying that the system enforces its own stated security rules. All testing must be performed on authorised test environments with synthetic test data only.

Application type: {{APPLICATION_TYPE}}
Authentication method: {{AUTH_METHOD}} (e.g. email/password, SSO, OAuth 2.0, API key)
Session management mechanism: {{SESSION_MECHANISM}} (e.g. JWT, session cookie, refresh token)
MFA in use: {{MFA_IN_USE}}
Key authentication flows: {{AUTH_FLOWS}}

Generate a checklist with the format:
Check ID | Category | What to test | Steps | Pass condition | Fail condition

Cover the following categories:

**Login flow — functional correctness**
- Valid credentials allow access
- Invalid password is rejected with an appropriate error (message must not reveal whether the username exists vs the password is wrong)
- Non-existent username is rejected with the same error message as invalid password (user enumeration prevention)
- Email and username fields handle case sensitivity consistently with the registration behaviour
- Login with a disabled or suspended account is rejected with an appropriate message

**Credential handling**
- Password is not visible in the request URL or server logs (ensure POST, not GET)
- Password field content is masked by default
- Autocomplete=off or appropriate browser credential management is applied to the password field
- Error response does not include the submitted password

**Session lifecycle**
- A valid session is created after successful login
- Session token or cookie is correctly scoped (HttpOnly, Secure, SameSite attributes on cookies)
- Session is invalidated on logout — token cannot be reused after logout
- Session expires after the documented idle timeout
- Session expires after the documented absolute timeout
- Concurrent login behaviour matches the documented policy (e.g. new login invalidates previous session)

**Token behaviour** (if JWT or token-based)
- Token contains only the data the application needs — does not expose internal IDs, roles, or sensitive fields unnecessarily
- Token expiry is enforced — an expired token is rejected
- Token with a modified payload is rejected (integrity validation)

**Multi-factor authentication** (if {{MFA_IN_USE}} is yes)
- MFA is enforced for the appropriate roles and flows
- An expired or reused MFA code is rejected
- MFA bypass paths are tested (password reset flow, API endpoints)

**Password reset**
- Reset link or token expires after the documented TTL
- A reset link can only be used once
- Reset confirmation does not reveal whether the email address exists in the system

After the checklist, note: this checklist covers QA-level functional verification, not a penetration test. Findings should go through your standard defect process. Engage a security professional for a full authentication security assessment.

You are a QA engineer specialising in access control and authorisation testing. Generate an RBAC and authorisation testing checklist for the system described below.

SCOPE: This checklist covers QA-level functional testing — verifying that the application enforces its documented access control rules. All testing must use authorised test environments and synthetic test accounts only. Never use real customer accounts or production data.

System or application: {{SYSTEM_NAME}}
User roles and their permissions:
{{ROLES_AND_PERMISSIONS}}

Resources and operations to test (e.g. endpoints, pages, actions):
{{RESOURCES_AND_OPERATIONS}}

Role assignment mechanism: {{ROLE_ASSIGNMENT}}

Generate a checklist with the format:
Check ID | Role | Resource / Action | Test scenario | Expected result | Pass condition

Cover the following categories:

**Positive access (each role can do what it should)**
For each role and permitted resource/action: verify the operation succeeds with a valid, in-scope token or session.

**Negative access — horizontal (role boundary enforcement)**
For each role, attempt to access resources and perform actions that are restricted to other roles at the same level. Expect 403 Forbidden or equivalent.

**Negative access — vertical (privilege escalation prevention)**
For each non-admin role, attempt to access admin-only resources or perform admin-only actions. Expect 403 Forbidden.

**Cross-user access (direct object reference)**
For each role, attempt to access another user's private resource by modifying an ID in the request (e.g. change userId, orderId, accountId to one belonging to a different synthetic test user). Expect 403 Forbidden or 404 Not Found.

**Role assignment and elevation**
- Can a standard user modify their own role via the API or UI?
- Can a standard user assign a higher role to another user?
- Is role modification correctly audited or logged?

**Unauthenticated access**
For each protected resource, verify it is inaccessible without authentication (expect 401).

**Edge cases**
- Resource accessed with a valid token for a deleted or deactivated account
- Resource accessed after a role change (token may be stale — test token refresh behaviour)

For each check, clearly state which test accounts are required (e.g. "requires: admin-test-1, standard-user-test-2").

After the checklist, note: these tests verify functional enforcement of documented access rules. A formal penetration test is needed to assess implementation-level vulnerabilities.

You are a senior QA engineer with security awareness. Generate a safe, QA-focused test planning guide covering the OWASP Top 10 for the application described below.

IMPORTANT SCOPE: This guide is for functional QA testing — verifying that documented security controls exist and behave correctly. It does not include exploit code, offensive payloads, credential harvesting, automated vulnerability scanning, or penetration testing. All testing must be on authorised test environments with synthetic data only.

Application type: {{APPLICATION_TYPE}}
Key features to consider: {{KEY_FEATURES}}
Authentication and authorisation mechanisms: {{AUTH_MECHANISMS}}
Data sensitivity categories (describe types, not values): {{DATA_CATEGORIES}}
Current security controls known to be in place: {{SECURITY_CONTROLS}}

For each of the following OWASP Top 10 categories, provide:
- **Category**: name and brief plain-English explanation
- **QA can test (functional checks)**: what a QA engineer can verify functionally without exploit code
- **QA cannot test (needs security specialist)**: what requires a penetration tester or automated DAST tool
- **Specific test ideas for {{APPLICATION_TYPE}}**: 2–3 concrete, safe test scenarios relevant to this application
- **What a failure looks like**: observable symptoms a QA engineer would notice

OWASP Top 10 categories to cover:
1. A01 Broken Access Control
2. A02 Cryptographic Failures (from a QA perspective: data exposure checks — not cryptographic implementation)
3. A03 Injection (functional validation testing — not crafting injection payloads)
4. A04 Insecure Design (design-level red flags a QA can spot during requirements review)
5. A05 Security Misconfiguration (observable behaviours: verbose errors, default credentials still active, unnecessary features exposed)
6. A06 Vulnerable and Outdated Components (process check — does your team have a dependency audit process?)
7. A07 Identification and Authentication Failures (functional auth testing — covered in auth checklist)
8. A08 Software and Data Integrity Failures (from a QA lens: update/deploy process checks, dependency verification)
9. A09 Security Logging and Monitoring Failures (QA checks: are actions logged, are critical events alerted?)
10. A10 Server-Side Request Forgery (SSRF) (functional boundary testing for URL inputs)

After the guide, include a clear statement:
- This guide enables QA-level coverage of observable OWASP Top 10 risks; it does not replace a formal penetration test
- Engage a qualified security professional for implementation-level vulnerability testing
- All test scenarios must be executed only on authorised, isolated test environments

You are a QA engineer who has found a security issue during testing. Write a clear, structured security bug report that communicates the risk to the engineering and security team.

IMPORTANT: This report is for internal use in an authorised test environment. Do not include working exploit code, payloads that could be directly reused to attack systems, or sensitive production system details. The goal is to help the team understand and fix the issue, not to document attack techniques.

Issue type (describe the category): {{ISSUE_TYPE}}
Where the issue was found: {{LOCATION}}
What the issue is (describe the behaviour, not the exploit): {{ISSUE_DESCRIPTION}}
How you found it (general approach, not step-by-step exploit): {{DISCOVERY_METHOD}}
What the potential impact is: {{POTENTIAL_IMPACT}}
Your test environment: {{TEST_ENVIRONMENT}}
User role or session state when found: {{USER_CONTEXT}}
Any evidence (screenshots, response snippets — remove all real user data and tokens): {{EVIDENCE_DESCRIPTION}}

Write a security bug report with the following structure:

**Summary**
One clear sentence describing the security issue and its impact category (e.g. "Authenticated users can access other users' order data via a predictable ID in the order detail endpoint").

**Severity and priority**
Suggested severity (Critical / High / Medium / Low) with justification based on:
- Data or functionality at risk
- Whether authentication is required to exploit it
- Number of users potentially affected
- Business or compliance impact

**Affected component**
Specific page, endpoint, or feature where the issue exists.

**User context**
What role or session state is needed to reach the vulnerable state.

**Steps to reproduce** (functional description only — no exploit payloads)
Numbered steps an engineer can follow to observe the behaviour in a test environment with synthetic data. Steps must not include working attack payloads, credentials, or production system references.

**Observed behaviour**
What the system currently does that it should not.

**Expected behaviour**
What the system should do instead.

**Potential impact**
Plain-language description of what could happen if this issue exists in production — what data, functionality, or users are at risk.

**Evidence**
Description of evidence available (remove all real tokens, credentials, customer data, and internal system paths from any evidence before including it).

**Suggested fix direction**
Non-prescriptive suggestion of the type of fix needed (e.g. "enforce ownership check on the server side before returning order data"). The engineering team decides the implementation.

**Handling note**
If the severity is High or Critical, note that this ticket should be reviewed with restricted visibility and handled through the organisation's security incident process.