보안 프롬프트

엔트리급 AI 모델로 코딩할 때, 아래 프롬프트를 복사하여 보안 점검을 수행하세요.

번역 보기
프롬프트는 AI 에디터(Cursor 등)에 최적화된 '체크리스트 주도(Checklist-driven)' 방식으로 작성되었습니다. 복사 후 에이전트에게 전달하면 안전하고 체계적인 전체 코드 점검이 시작됩니다.
🛡️

SQL Injection

SQL 쿼리에 악의적 입력을 삽입하여 데이터베이스를 조작하는 공격 유형의 점검 프롬프트입니다.

SQL Injection 기본 점검

사용자 입력이 SQL 쿼리에 직접 삽입되는지 전반적으로 점검합니다.

Review the following code for SQL Injection vulnerabilities. Check specifically for:

1. User input directly concatenated or interpolated into SQL query strings
2. Use of string formatting (f-strings, format(), %, +) to build SQL queries
3. Whether parameterized queries or prepared statements are used consistently
4. ORM usage — check if any raw SQL methods (e.g., raw(), execute(), textual SQL) bypass the ORM's built-in protections
5. Dynamic table or column names constructed from user input without whitelisting
6. Stored procedures that internally use dynamic SQL (EXEC, sp_executesql)

For each vulnerability found, provide:
- The exact line(s) of code
- The type of SQL Injection it is vulnerable to
- A concrete fix using parameterized queries or the appropriate ORM method

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

Union-based SQL Injection 점검

UNION 구문을 이용하여 다른 테이블의 데이터를 추출할 수 있는지 점검합니다.

Analyze the following code for Union-based SQL Injection vulnerabilities. Focus on:

1. Any SQL query where user input controls the WHERE clause or similar filtering logic
2. Whether the application returns query results directly to the user (making UNION attacks viable)
3. Check if the number of columns in the original query can be discovered through ORDER BY or UNION SELECT NULL techniques
4. Whether the application reveals column data types through error messages or output formatting
5. Look for queries that combine multiple user-controlled parameters — each is a potential injection point

For each finding:
- Show the vulnerable code
- Demonstrate a sample UNION-based payload that could extract data
- Provide the secure fix

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

Error-based SQL Injection 점검

데이터베이스 에러 메시지를 통해 정보가 유출될 수 있는지 점검합니다.

Analyze the following code for Error-based SQL Injection vulnerabilities. Check for:

1. Database error messages exposed to the end user (e.g., stack traces, raw SQL errors)
2. Verbose error handling that reveals database type, version, table names, or column names
3. Use of functions like EXTRACTVALUE(), UPDATEXML(), or CONVERT() that can be exploited for error-based data extraction
4. Generic exception handlers that pass database errors directly to HTTP responses
5. Debug mode enabled in production that shows detailed SQL errors
6. Lack of custom error pages — default framework error pages revealing internal details

For each finding:
- Identify the exact error exposure path
- Show how an attacker could extract data via crafted error-triggering payloads
- Provide fixes: custom error handling, generic user-facing messages, proper logging

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

Blind SQL Injection 점검

Boolean 또는 Time-based 기법으로 데이터를 추론할 수 있는지 점검합니다.

Analyze the following code for Blind SQL Injection vulnerabilities. Check for:

1. Boolean-based blind injection: queries where true/false conditions cause different application responses (e.g., different page content, HTTP status codes, redirects)
2. Time-based blind injection: queries where injected SLEEP(), WAITFOR DELAY, BENCHMARK(), or pg_sleep() calls can cause measurable response delays
3. Any conditional logic in SQL built from user input, even if no data is directly returned
4. API endpoints that return binary responses (success/failure, exists/not-exists) based on database queries with user-controlled parameters
5. Login forms, search functions, or existence-check endpoints that are common blind SQLi targets

For each finding:
- Show the vulnerable query
- Explain the blind extraction technique applicable (boolean or time-based)
- Demonstrate a sample payload
- Provide the parameterized query fix

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

SQL Injection 대응방법

Prepared Statement, ORM, 입력 검증 등 SQL Injection 방어 전략을 점검합니다.

Review the following code and verify that proper SQL Injection defenses are implemented. Check each of these defense layers:

1. **Parameterized Queries**: All SQL queries MUST use parameterized queries (prepared statements) with placeholders (?, :param, $1). No exceptions.
2. **ORM Proper Usage**: If using an ORM (SQLAlchemy, Prisma, Sequelize, etc.), verify that:
   - No raw() or execute() methods are used with string concatenation
   - Query builder methods are used correctly with bound parameters
3. **Input Validation**: User inputs are validated/sanitized BEFORE reaching the database layer:
   - Whitelist validation for expected patterns (e.g., IDs should be integers)
   - Reject or escape special SQL characters where parameterization isn't possible (e.g., dynamic identifiers)
4. **Least Privilege**: Database connection uses a user with minimal necessary permissions (no DROP, no GRANT)
5. **Error Handling**: Database errors are caught and replaced with generic messages; raw SQL errors never reach the client
6. **WAF / Middleware**: Check for SQL injection detection middleware or input sanitization layers

Provide a summary table of all defense measures present (✅) or missing (❌).

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.
목차로 돌아가기
🌐

XSS (Cross-Site Scripting)

악성 스크립트를 웹 페이지에 삽입하여 사용자 브라우저에서 실행시키는 공격 유형의 점검 프롬프트입니다.

XSS 기본 점검

사용자 입력이 HTML이나 JavaScript로 렌더링되는 경로를 전반적으로 점검합니다.

Review the following code for Cross-Site Scripting (XSS) vulnerabilities. Check for:

1. User input rendered directly in HTML without encoding or escaping
2. Use of dangerous APIs: innerHTML, outerHTML, document.write(), insertAdjacentHTML()
3. React: Use of dangerouslySetInnerHTML without sanitization
4. Template engines: Unescaped output syntax (e.g., {{{ }}} in Handlebars, | safe in Jinja2, v-html in Vue)
5. User input placed in dangerous contexts:
   - Inside <script> tags
   - In HTML event handlers (onclick, onerror, onload)
   - In href/src attributes (javascript: protocol)
   - In CSS (expression(), url())
6. URL parameters or hash fragments reflected directly into the page
7. DOM-based XSS: JavaScript reading from location, document.referrer, or window.name and writing to DOM

For each vulnerability found:
- Identify the input source and the output sink
- Classify as Stored, Reflected, or DOM-based XSS
- Provide the specific fix (output encoding, sanitization library, or safe API)

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

Stored XSS 점검

데이터베이스에 저장된 악성 스크립트가 다른 사용자에게 렌더링되는지 점검합니다.

Analyze the following code specifically for Stored (Persistent) XSS vulnerabilities. Check:

1. Any user input that is saved to a database and later rendered on a page — trace the full flow:
   - Input → Storage (DB/file/cache) → Retrieval → Rendering
2. Common stored XSS vectors:
   - User profile fields (name, bio, avatar URL)
   - Comments, posts, messages, reviews
   - File names and metadata
   - Form submissions displayed in admin panels
3. Verify output encoding is applied at the RENDERING stage, not just at input
4. Check if HTML sanitization libraries (DOMPurify, bleach, sanitize-html) are used for rich text
5. Verify sanitization is applied server-side, not just client-side (client-side can be bypassed)
6. Check for second-order XSS: input stored safely but rendered unsafely in a different context

For each finding:
- Trace the complete data flow from input to storage to output
- Show a proof-of-concept payload
- Provide the fix at the correct layer (output encoding or input sanitization)

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

Reflected XSS 점검

URL 파라미터나 요청값이 응답에 그대로 반영되는지 점검합니다.

Analyze the following code specifically for Reflected XSS vulnerabilities. Check:

1. URL query parameters reflected directly into the HTML response
2. Form inputs that are echoed back in error messages or confirmation pages
3. Search queries displayed on the results page without encoding
4. HTTP headers (Referer, User-Agent) reflected in the page
5. API responses that include request data and are rendered client-side
6. Redirect URLs constructed from user input (open redirect + XSS combo)
7. 404/error pages that display the requested URL path

For each finding:
- Show the exact request parameter and where it appears in the response
- Provide a crafted URL demonstrating the reflection
- Specify the fix: output encoding appropriate to the context (HTML, JS, URL, CSS)

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

XSS 공격 시나리오 분석

실제 공격 벡터를 기반으로 다양한 XSS 시나리오를 진단합니다.

For the following code, analyze potential real-world XSS attack scenarios. Consider these attack vectors:

1. **Basic script injection**: <script>alert(1)</script> and variations
2. **Event handler injection**: <img src=x onerror=alert(1)>, <svg onload=alert(1)>
3. **Attribute escape**: Breaking out of HTML attributes with " or ' to inject event handlers
4. **JavaScript context injection**: Injecting into inline <script> blocks or JS variables
5. **URL scheme attacks**: javascript:, data:, vbscript: in href/src attributes
6. **CSS injection**: expression(), url(), @import used for script execution
7. **Encoding bypasses**: HTML entities, URL encoding, Unicode, null bytes, mixed case
8. **Filter evasion**: Techniques to bypass common XSS filters (tag nesting, attribute injection, protocol-relative URLs)
9. **Mutation XSS (mXSS)**: Payloads that appear safe but become dangerous after browser HTML parsing/mutation

For each applicable scenario:
- Show the specific payload that would work against this code
- Explain the impact (what an attacker could achieve)
- Rate the severity (Critical/High/Medium/Low)
- Recommend the defense

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

쿠키 탈취 점검

document.cookie 접근, HttpOnly 미설정 등 쿠키 탈취 경로를 점검합니다.

Review the following code for cookie theft vulnerabilities through XSS. Check:

1. **HttpOnly flag**: Are session cookies and authentication tokens set with HttpOnly flag? (Prevents document.cookie access)
2. **Secure flag**: Are cookies set with Secure flag? (Prevents transmission over HTTP)
3. **SameSite attribute**: Are cookies set with SameSite=Strict or SameSite=Lax? (Prevents CSRF-based cookie exfiltration)
4. **document.cookie access**: Is there any JavaScript code that reads document.cookie? Can an XSS payload access it?
5. **Token storage**: Are sensitive tokens stored in cookies, localStorage, or sessionStorage? (localStorage/sessionStorage are always accessible via JS)
6. **Cookie scope**: Are cookies scoped correctly with Domain and Path? (Overly broad scope increases theft surface)
7. **Exfiltration paths**: If XSS exists, can cookies be sent to an external server via:
   - fetch() / XMLHttpRequest
   - new Image().src
   - navigator.sendBeacon()
   - WebSocket connections

For each finding:
- Show the specific vulnerability
- Demonstrate the cookie theft attack chain (XSS → cookie access → exfiltration)
- Provide fixes: cookie flags, Content-Security-Policy, token architecture changes

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

XSS 대응방안

CSP, 출력 인코딩, 입력 새니타이징 등 XSS 방어 전략을 점검합니다.

Review the following code and verify that comprehensive XSS defenses are implemented. Check each defense layer:

1. **Output Encoding**: All user-controlled data is encoded appropriately for its context:
   - HTML context: HTML entity encoding (&lt; &gt; &amp; &quot; &#x27;)
   - JavaScript context: JavaScript encoding (\xHH or \uHHHH)
   - URL context: percent encoding
   - CSS context: CSS hex encoding
2. **Content Security Policy (CSP)**:
   - Is a CSP header set? What directives are used?
   - Is 'unsafe-inline' or 'unsafe-eval' present? (These weaken CSP significantly)
   - Are nonces or hashes used for inline scripts?
3. **Input Sanitization**:
   - For rich text/HTML input: Is a sanitization library used? (DOMPurify, bleach, sanitize-html)
   - Is sanitization applied server-side?
   - Is a whitelist approach used (allowing only safe tags/attributes)?
4. **Framework Protections**:
   - React: auto-escaping in JSX, no unnecessary dangerouslySetInnerHTML
   - Angular: built-in sanitization, no bypassSecurityTrust* misuse
   - Vue: no v-html with user input
5. **HTTP Headers**: X-Content-Type-Options: nosniff, X-Frame-Options, Referrer-Policy
6. **Cookie Protection**: HttpOnly, Secure, SameSite flags on all sensitive cookies

Provide a defense coverage matrix (✅ present / ❌ missing / ⚠️ partial) for each layer.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.
목차로 돌아가기
🔐

인증 및 세션 관리

로그인, 세션 토큰, 비밀번호 저장 등 인증 관련 보안 점검 프롬프트입니다.

인증 로직 점검

로그인 처리, 비밀번호 해싱, 브루트포스 방어 등을 점검합니다.

Review the following authentication code for security vulnerabilities. Check:

1. **Password Hashing**: Are passwords hashed with a strong algorithm (bcrypt, scrypt, Argon2)? Never MD5, SHA1, or plain SHA256.
2. **Salt Usage**: Are unique salts generated per password? (Not a global salt or no salt)
3. **Brute Force Protection**: Is there rate limiting, account lockout, or CAPTCHA after failed attempts?
4. **Timing Attacks**: Does the login logic use constant-time comparison for passwords/tokens?
5. **Credential Enumeration**: Does the login error message differentiate between "user not found" and "wrong password"? (It shouldn't)
6. **Password Policy**: Is there minimum length, complexity requirements?
7. **Multi-Factor Authentication**: Is MFA available or enforced for sensitive operations?
8. **Secure Password Reset**: Token-based reset with expiration, single-use tokens, no password in URL/email

For each finding, provide severity and the specific fix.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

세션 관리 점검

세션 토큰 생성, 만료, 고정 공격(Session Fixation) 등을 점검합니다.

Review the following code for session management vulnerabilities. Check:

1. **Session ID Generation**: Are session IDs generated using cryptographically secure random number generators? (Minimum 128 bits of entropy)
2. **Session Fixation**: Is the session ID regenerated after successful authentication? (Prevents session fixation attacks)
3. **Session Expiration**: Are there both idle timeout and absolute timeout configured?
4. **Session Invalidation**: Is the session properly destroyed on logout? (Server-side invalidation, not just cookie deletion)
5. **Concurrent Sessions**: Is there a limit on concurrent sessions per user?
6. **Session Storage**: Where are sessions stored? (Server-side storage preferred over client-side)
7. **Cookie Attributes**: HttpOnly, Secure, SameSite, appropriate Domain/Path scope
8. **JWT Specific** (if applicable): Algorithm validation (no "none"), proper expiration (exp), audience/issuer validation

For each finding, explain the attack vector and provide the fix.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

CSRF 점검

Cross-Site Request Forgery 방어 토큰이 올바르게 구현되었는지 점검합니다.

Review the following code for Cross-Site Request Forgery (CSRF) vulnerabilities. Check:

1. **CSRF Tokens**: Are anti-CSRF tokens generated and validated for all state-changing requests (POST, PUT, DELETE)?
2. **Token Implementation**: Is the CSRF token:
   - Cryptographically random and unique per session?
   - Bound to the user's session?
   - Validated server-side on every state-changing request?
3. **SameSite Cookies**: Are cookies set with SameSite=Strict or SameSite=Lax?
4. **Custom Headers**: For AJAX requests, is a custom header (e.g., X-Requested-With) required and validated?
5. **Referer/Origin Validation**: Is the Origin or Referer header checked as an additional defense?
6. **GET Side Effects**: Do any GET requests perform state-changing operations? (They shouldn't)
7. **Login CSRF**: Is CSRF protection applied to the login form itself?

For each finding, classify the risk and provide the implementation fix.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.
목차로 돌아가기
📁

파일 및 데이터 처리

파일 업로드, 경로 조작, 데이터 직렬화 등 데이터 처리 보안 점검 프롬프트입니다.

파일 업로드 점검

파일 타입 검증, 경로 조작, 실행 가능 파일 업로드 등을 점검합니다.

Review the following file upload code for security vulnerabilities. Check:

1. **File Type Validation**: Is the file type validated using content/magic bytes (not just file extension)? Extensions can be spoofed.
2. **Allowed Extensions Whitelist**: Is there a strict whitelist of allowed file extensions? (Blacklists are insufficient)
3. **File Size Limits**: Is there a maximum file size enforced server-side?
4. **File Name Sanitization**: Is the original filename sanitized or replaced with a generated name? Check for:
   - Path traversal (../, ..\)
   - Null bytes (%00)
   - Special characters that could cause issues on the filesystem
5. **Storage Location**: Are uploaded files stored outside the web root? Can they be accessed/executed directly via URL?
6. **Execution Prevention**: Is the upload directory configured to prevent script execution (e.g., no PHP/JSP/ASPX execution)?
7. **Virus Scanning**: Are uploaded files scanned for malware?
8. **Image-Specific**: For image uploads, is the image re-processed/re-encoded to strip embedded code?

For each vulnerability, show the attack scenario and the fix.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

데이터 직렬화 점검

역직렬화 취약점, 안전하지 않은 JSON/XML 파싱 등을 점검합니다.

Review the following code for insecure deserialization and data parsing vulnerabilities. Check:

1. **Insecure Deserialization**: Is untrusted data deserialized using native serialization (pickle, Java ObjectInputStream, PHP unserialize, Marshal)?
2. **JSON Parsing**: Is user-provided JSON parsed safely? Check for:
   - Prototype pollution (JavaScript)
   - Excessive nesting causing DoS
   - Custom revivers/parsers that could execute code
3. **XML Parsing**: Check for:
   - XML External Entity (XXE) injection — is external entity processing disabled?
   - XML bombs (Billion Laughs) — is entity expansion limited?
   - XPath injection in queries using user input
4. **YAML Parsing**: Is yaml.safe_load() used instead of yaml.load()? (Unsafe YAML can execute arbitrary code)
5. **Type Confusion**: Can an attacker send unexpected data types that cause different code paths?

For each finding, show the exploit scenario and provide the safe alternative.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.
목차로 돌아가기
🔑

API 및 네트워크 보안

CORS, Rate Limiting, API 키 관리 등 API 보안 점검 프롬프트입니다.

API 보안 점검

CORS 설정, Rate Limiting, 인증 토큰 검증 등을 점검합니다.

Review the following API code for security vulnerabilities. Check:

1. **CORS Configuration**:
   - Is Access-Control-Allow-Origin set to a specific domain (not * for authenticated endpoints)?
   - Are Access-Control-Allow-Methods and Access-Control-Allow-Headers properly restricted?
   - Is Access-Control-Allow-Credentials used correctly?
2. **Rate Limiting**: Are rate limits enforced per-user, per-IP, or per-API-key to prevent abuse and DoS?
3. **Authentication**: Are all endpoints that require authentication properly protected? Check for:
   - Missing auth middleware on sensitive routes
   - Broken function-level authorization (can a regular user access admin endpoints?)
   - IDOR (Insecure Direct Object Reference) — can a user access another user's data by changing an ID?
4. **Input Validation**: Are request bodies, query parameters, and headers validated against a schema?
5. **Response Data**: Are API responses filtered to exclude sensitive fields? (No password hashes, internal IDs, etc.)
6. **HTTP Methods**: Are unused HTTP methods disabled?
7. **API Versioning**: Is there proper versioning to prevent breaking changes from exposing security issues?

For each finding, provide the severity and fix.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

API 키 관리 점검

하드코딩된 키, 키 노출, 키 로테이션 등을 점검합니다.

Review the following code for API key management vulnerabilities. Check:

1. **Hardcoded Secrets**: Are any API keys, tokens, passwords, or connection strings hardcoded in source code?
2. **Environment Variables**: Are secrets loaded from environment variables or a secrets manager (not config files committed to git)?
3. **Git History**: Is there a risk of secrets being in git history? (Check for .env files, config files with secrets)
4. **Client-Side Exposure**: Are any server-side API keys exposed to the client (browser JavaScript, mobile app bundles)?
5. **Key Rotation**: Is there a process for rotating API keys? Are old keys properly revoked?
6. **Key Scope**: Are API keys scoped to minimum necessary permissions?
7. **Logging**: Are API keys accidentally logged in application logs, error messages, or debug output?
8. **.gitignore**: Are .env, credentials, and key files properly listed in .gitignore?

For each finding, show where the exposure occurs and the remediation steps.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.
목차로 돌아가기
🔒

민감 정보 관리

시크릿 관리, 로깅 보안 등 민감 정보 보호 관련 점검 프롬프트입니다.

시크릿 관리 점검

환경변수 사용, .env 파일 관리, 소스코드 내 시크릿 탐지 등을 점검합니다.

Review the following code and project structure for secrets management vulnerabilities. Check:

1. **Hardcoded Secrets Detection**: Scan for patterns that indicate hardcoded secrets:
   - API keys (strings starting with sk-, pk-, AKIA, etc.)
   - Connection strings with embedded credentials
   - JWT secrets, encryption keys
   - OAuth client secrets
   - Database passwords
2. **Environment Variable Usage**: Are secrets properly externalized to environment variables?
3. **Secrets Manager**: For production, are secrets stored in a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.)?
4. **Default Credentials**: Are default/placeholder credentials (admin/admin, test/test) present?
5. **Encryption at Rest**: Are sensitive configuration values encrypted, not stored in plaintext?
6. **.env File Security**: Is .env listed in .gitignore? Are there .env.example files that accidentally contain real values?
7. **Docker/Container Secrets**: Are secrets passed securely (Docker secrets, K8s secrets) rather than as environment variables in Dockerfiles?

For each finding, provide the location and the secure alternative.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

로깅 보안 점검

민감 정보(비밀번호, 토큰 등)가 로그에 노출되는지 점검합니다.

Review the following code for logging security vulnerabilities. Check:

1. **Sensitive Data in Logs**: Are any of the following logged?
   - Passwords or password hashes
   - API keys, tokens, session IDs
   - Credit card numbers, SSNs, personal data (PII)
   - Full request/response bodies containing sensitive fields
2. **Log Injection**: Can user input be injected into log entries to forge log records or inject control characters?
3. **Log Level Configuration**: Is debug/verbose logging disabled in production?
4. **Structured Logging**: Are logs structured (JSON format) to prevent injection and ease filtering?
5. **Log Access Control**: Are log files protected with appropriate file permissions?
6. **Log Retention**: Is there a log retention policy? Are old logs securely deleted?
7. **Error Details**: Do error logs expose stack traces, file paths, or internal architecture to external users?

For each finding, show the sensitive data exposure and the fix (redaction, masking, or removal).

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.
목차로 돌아가기
⚙️

배포 및 설정 보안

HTTPS, 보안 헤더, 의존성 관리 등 배포 환경 보안 점검 프롬프트입니다.

배포 보안 점검

HTTPS 설정, 보안 헤더, 에러 페이지 정보 노출 등을 점검합니다.

Review the following deployment configuration and code for security issues. Check:

1. **HTTPS**: Is HTTPS enforced? Are HTTP requests redirected to HTTPS? Is HSTS (HTTP Strict Transport Security) configured?
2. **Security Headers**: Are the following headers set?
   - Content-Security-Policy (CSP)
   - X-Content-Type-Options: nosniff
   - X-Frame-Options: DENY or SAMEORIGIN
   - X-XSS-Protection: 0 (rely on CSP instead)
   - Referrer-Policy: strict-origin-when-cross-origin
   - Permissions-Policy (restrict camera, microphone, geolocation, etc.)
3. **Error Pages**: Do custom error pages avoid exposing stack traces, server versions, or internal paths?
4. **Server Information**: Are server version headers (Server, X-Powered-By) removed or obscured?
5. **Debug Mode**: Is debug mode disabled in production?
6. **Directory Listing**: Is directory listing disabled on the web server?
7. **TLS Configuration**: Is TLS 1.2+ enforced? Are weak cipher suites disabled?
8. **CORS in Production**: Is CORS configured for specific origins (not wildcard *)?

Provide a compliance checklist with ✅/❌ for each item.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.

의존성 보안 점검

npm/pip 패키지 취약점, 공급망 공격 방어 등을 점검합니다.

Review the following project's dependency management for security risks. Check:

1. **Known Vulnerabilities**: Are there dependencies with known CVEs? Run or recommend:
   - npm audit / yarn audit (Node.js)
   - pip-audit / safety check (Python)
   - bundle audit (Ruby)
   - cargo audit (Rust)
2. **Outdated Dependencies**: Are critical dependencies significantly outdated? (Especially security-related ones like auth libraries, crypto libraries)
3. **Lock File**: Is there a lock file (package-lock.json, yarn.lock, Pipfile.lock) committed to prevent supply chain attacks?
4. **Dependency Pinning**: Are dependencies pinned to specific versions (not floating ranges like ^, ~, *)?
5. **Typosquatting Risk**: Are all package names correct? (Check for common typosquatting patterns)
6. **Unused Dependencies**: Are there unused dependencies that increase the attack surface?
7. **Post-Install Scripts**: Do any dependencies run post-install scripts that could be malicious?
8. **Private Registry**: If using a private registry, is authentication configured properly?

Provide a risk assessment for each dependency category.

Target Context: Review the entire codebase/workspace.

Checklist-Driven Workflow Instructions:
1. Do NOT modify or generate any code yet.
2. First, scan the entire codebase to identify all files and components relevant to the vulnerabilities mentioned above.
3. Generate a step-by-step Security Audit & Remediation Checklist using a checkbox format (e.g., - [ ]). The checklist should list specific files or logical components to be audited.
4. Wait for my approval. Once I say "Proceed", execute the audit and remediation for the first item on the checklist.
5. After completing one step, wait for my confirmation before moving to the next unchecked item.
목차로 돌아가기