[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AGBBHZ9TH9YVD5CX4SRJS3":3,"skill-same:01M6AGBBHZ9TH9YVD5CX4SRJS3":126},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":37,"publishedAt":58,"linkOnly":59,"markdownContent":60,"markdownBody":61,"frontMatter":62,"refName":85,"commitSha":86,"skillDirectory":87,"forksCount":88,"repositoryHtmlUrl":89,"repositoryHomepageUrl":90,"ownerHtmlUrl":91,"ownerBlogUrl":92,"ownerDescription":93,"updatedAt":94,"install":95,"resources":108},"01M6AGBBHZ9TH9YVD5CX4SRJS3","testing-for-sensitive-data-exposure",null,"Identifying sensitive data exposure vulnerabilities including API key leakage, PII in responses, insecure storage, and unprotected data transmission during security assessments.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-sensitive-data-exposure\u002FSKILL.md",[18,23,26,29,34],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":35,"categoryName":36,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000033","数据分析师",[38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57],"testing for sensitive data exposure","data","testing","t1059","secrets","api","application-security","pii","api-keys","t1505","web-security","data-exposure","web-application-security","owasp","pr","web","storage","vulnerabilities","cybersecurity","security","2026-11-10 10:12:30",false,"---\nname: testing-for-sensitive-data-exposure\ndescription: Identifying sensitive data exposure vulnerabilities including API key\n  leakage, PII in responses, insecure storage, and unprotected data transmission during\n  security assessments.\ndomain: cybersecurity\nsubdomain: web-application-security\ntags:\n- penetration-testing\n- data-exposure\n- pii\n- owasp\n- web-security\n- api-keys\n- secrets\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_ai_rmf:\n- MEASURE-2.7\n- MAP-5.1\n- MANAGE-2.4\natlas_techniques:\n- AML.T0070\n- AML.T0066\n- AML.T0082\nnist_csf:\n- PR.PS-01\n- ID.RA-01\n- PR.DS-10\n- DE.CM-01\nmitre_attack:\n- T1190\n- T1059.007\n- T1505.003\n- T1083\n---\n\n# Testing for Sensitive Data Exposure\n\n## When to Use\n\n- During authorized penetration tests when assessing data protection controls\n- When evaluating applications for GDPR, PCI DSS, HIPAA, or other data protection compliance\n- For identifying leaked API keys, credentials, tokens, and secrets in application responses\n- When testing whether sensitive data is properly encrypted in transit and at rest\n- During security assessments of APIs that handle PII, financial data, or health records\n\n## Prerequisites\n\n- **Authorization**: Written penetration testing agreement with data handling scope\n- **Burp Suite Professional**: For intercepting and analyzing responses for sensitive data\n- **trufflehog**: Secret scanning tool (`pip install trufflehog`)\n- **gitleaks**: Git repository secret scanner (`go install github.com\u002Fgitleaks\u002Fgitleaks\u002Fv8@latest`)\n- **curl\u002Fhttpie**: For manual endpoint testing\n- **Browser DevTools**: For examining local storage, session storage, and cached data\n- **testssl.sh**: TLS configuration testing tool\n\n## Workflow\n\n### Step 1: Scan for Secrets in Client-Side Code\n\nSearch JavaScript files, HTML source, and other client-side resources for exposed secrets.\n\n```bash\n# Download and search JavaScript files for secrets\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | \\\n  grep -oP 'src=\"[^\"]*\\.js[^\"]*\"' | \\\n  grep -oP '\"[^\"]*\"' | tr -d '\"' | while read js; do\n    echo \"=== Scanning: $js ===\"\n    # Handle relative URLs\n    if [[ \"$js\" == \u002F* ]]; then\n      curl -s \"https:\u002F\u002Ftarget.example.com$js\"\n    else\n      curl -s \"$js\"\n    fi | grep -inE \\\n      \"(api[_-]?key|apikey|api[_-]?secret|aws[_-]?access|aws[_-]?secret|private[_-]?key|password|secret|token|auth|credential|AKIA[0-9A-Z]{16})\" \\\n      | head -20\ndone\n\n# Search for common secret patterns\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Fstatic\u002Fapp.js\" | grep -nP \\\n  \"(AIza[0-9A-Za-z-_]{35}|AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{48}|ghp_[a-zA-Z0-9]{36}|xox[bpsa]-[0-9a-zA-Z-]{10,})\"\n\n# Check source maps for exposed source code\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Fstatic\u002Fapp.js.map\" | head -c 500\n# Source maps may contain original source code with embedded secrets\n\n# Search HTML source for exposed data\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | grep -inE \\\n  \"(api_key|secret|password|token|private_key|database_url|smtp_password)\" | head -20\n\n# Check for exposed .env or configuration files\nfor file in .env .env.local .env.production config.json settings.json \\\n  .aws\u002Fcredentials .docker\u002Fconfig.json; do\n  status=$(curl -s -o \u002Fdev\u002Fnull -w \"%{http_code}\" \\\n    \"https:\u002F\u002Ftarget.example.com\u002F$file\")\n  if [ \"$status\" == \"200\" ]; then\n    echo \"FOUND: $file ($status)\"\n  fi\ndone\n```\n\n### Step 2: Analyze API Responses for Data Over-Exposure\n\nCheck if API endpoints return more data than necessary.\n\n```bash\n# Fetch user profile and examine response fields\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002Fme\" | jq .\n\n# Look for sensitive fields that should not be exposed:\n# - password, password_hash, password_salt\n# - ssn, social_security_number, national_id\n# - credit_card_number, card_cvv, card_expiry\n# - api_key, secret_key, access_token, refresh_token\n# - internal_id, database_id\n# - ip_address, session_id\n# - date_of_birth, drivers_license\n\n# Check list endpoints for excessive data\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\" | jq '.[0] | keys'\n\n# Compare public vs authenticated responses\necho \"=== Public ===\"\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002F1\" | jq 'keys'\necho \"=== Authenticated ===\"\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002F1\" | jq 'keys'\n\n# Check error responses for information leakage\ncurl -s -X POST \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"invalid\": \"data\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\" | jq .\n# Look for: stack traces, database queries, internal paths, version info\n\n# Test for PII in search\u002Fautocomplete responses\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fsearch?q=john\" | jq .\n# May return full user records instead of just names\n```\n\n### Step 3: Test Data Transmission Security\n\nVerify that sensitive data is encrypted during transmission.\n\n```bash\n# Check TLS configuration\n# Using testssl.sh\n.\u002Ftestssl.sh \"https:\u002F\u002Ftarget.example.com\"\n\n# Quick TLS checks with curl\ncurl -s -v \"https:\u002F\u002Ftarget.example.com\u002F\" 2>&1 | grep -E \"(SSL|TLS|cipher|subject)\"\n\n# Check for HTTP (non-HTTPS) endpoints\ncurl -s -I \"http:\u002F\u002Ftarget.example.com\u002F\" | head -5\n# Should redirect to HTTPS\n\n# Check for mixed content (HTTP resources on HTTPS pages)\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | grep -oP \"http:\u002F\u002F[^\\\"'> ]+\" | head -20\n\n# Check if sensitive forms submit over HTTPS\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | grep -oP 'action=\"[^\"]*\"'\n# Form action should use HTTPS\n\n# Check for sensitive data in URL parameters (query string)\n# URLs are logged in browser history, server logs, proxy logs, Referer headers\n# Look for: \u002Flogin?username=admin&password=secret\n# \u002Fapi\u002Fdata?ssn=123-45-6789\n# \u002Fsearch?credit_card=4111111111111111\n\n# Check WebSocket encryption\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | grep -oP \"(ws|wss):\u002F\u002F[^\\\"'> ]+\"\n# ws:\u002F\u002F is unencrypted; should only use wss:\u002F\u002F\n```\n\n### Step 4: Examine Browser Storage for Sensitive Data\n\nCheck local storage, session storage, cookies, and cached responses.\n\n```bash\n# Check what cookies are set and their security attributes\ncurl -s -I \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | grep -i \"set-cookie\"\n\n# In browser DevTools (Application tab):\n# 1. Local Storage: Check for stored tokens, PII, credentials\n# 2. Session Storage: Check for temporary sensitive data\n# 3. IndexedDB: Check for cached application data\n# 4. Cache Storage: Check for cached API responses containing PII\n# 5. Cookies: Check for sensitive data in cookie values\n\n# Common insecure storage patterns:\n# localStorage.setItem('access_token', 'eyJ...');  \u002F\u002F XSS can steal\n# localStorage.setItem('user', JSON.stringify({email: '...', ssn: '...'}));\n# sessionStorage.setItem('credit_card', '4111...');\n\n# Check for autocomplete on sensitive forms\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | \\\n  grep -oP '\u003Cinput[^>]*(password|credit|ssn|card)[^>]*>' | \\\n  grep -v 'autocomplete=\"off\"'\n# Password and credit card fields should have autocomplete=\"off\"\n\n# Check Cache-Control headers on sensitive pages\nfor page in \u002Faccount\u002Fprofile \u002Fapi\u002Fusers\u002Fme \u002Ftransactions \u002Fbilling; do\n  echo -n \"$page: \"\n  curl -s -I \"https:\u002F\u002Ftarget.example.com$page\" \\\n    -H \"Authorization: Bearer $TOKEN\" | \\\n    grep -i \"cache-control\" | tr -d '\\r'\n  echo\ndone\n# Sensitive pages should have: Cache-Control: no-store\n```\n\n### Step 5: Scan Git Repositories and Source Code for Secrets\n\nSearch for accidentally committed secrets in version control.\n\n```bash\n# Check for exposed .git directory\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F.git\u002Fconfig\"\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F.git\u002FHEAD\"\n\n# If .git is exposed, use git-dumper to download\n# pip install git-dumper\ngit-dumper https:\u002F\u002Ftarget.example.com\u002F.git \u002Ftmp\u002Ftarget-repo\n\n# Scan downloaded repository with trufflehog\ntrufflehog filesystem \u002Ftmp\u002Ftarget-repo\n\n# Scan with gitleaks\ngitleaks detect --source \u002Ftmp\u002Ftarget-repo -v\n\n# If GitHub\u002FGitLab repository is available (authorized scope)\ntrufflehog github --org target-organization --token $GITHUB_TOKEN\ngitleaks detect --source https:\u002F\u002Fgithub.com\u002Forg\u002Frepo -v\n\n# Common secrets found in repositories:\n# - AWS access keys (AKIA...)\n# - Database connection strings\n# - API keys (Google, Stripe, Twilio, SendGrid)\n# - Private SSH keys\n# - JWT signing secrets\n# - OAuth client secrets\n# - SMTP credentials\n\n# Search for secrets in Docker images\n# docker save target-image:latest | tar x -C \u002Ftmp\u002Fdocker-layers\n# Search each layer for credentials\n```\n\n### Step 6: Test Data Masking and Redaction\n\nVerify that sensitive data is properly masked in the application.\n\n```bash\n# Check if credit card numbers are fully displayed\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fpayment-methods\" | jq .\n# Should show: **** **** **** 4242, not full number\n\n# Check if SSN\u002Fnational ID is masked\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002Fme\" | jq '.ssn'\n# Should show: ***-**-6789, not full SSN\n\n# Check API responses for password hashes\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\" | jq '.[].password \u002F\u002F empty'\n# Should return nothing; password hashes should never be in API responses\n\n# Check export\u002Fdownload features for unmasked data\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002Fexport?format=csv\" | head -5\n# CSV exports often contain unmasked PII\n\n# Check logging endpoints for sensitive data\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fadmin\u002Flogs\" | \\\n  grep -iE \"(password|token|secret|credit_card|ssn)\" | head -10\n# Logs should not contain sensitive data in plaintext\n\n# Test for sensitive data in error messages\ncurl -s -X POST \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"email\":\"duplicate@test.com\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fregister\"\n# Should not reveal: \"User with email duplicate@test.com already exists\"\n# Should show: \"Registration failed\" (generic)\n```\n\n## Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| **Sensitive Data Exposure** | Unintended disclosure of PII, credentials, financial data, or health records |\n| **Data Over-Exposure** | API returning more data fields than the client needs |\n| **Secret Leakage** | API keys, tokens, or credentials exposed in client-side code or logs |\n| **Data at Rest** | Sensitive data stored in databases, files, or backups without encryption |\n| **Data in Transit** | Sensitive data transmitted over network without TLS encryption |\n| **Data Masking** | Replacing sensitive data with redacted values (e.g., showing last 4 digits of credit card) |\n| **PII** | Personally Identifiable Information - data that can identify an individual |\n| **Information Leakage** | Excessive error messages, stack traces, or debug information in responses |\n\n## Tools & Systems\n\n| Tool | Purpose |\n|------|---------|\n| **Burp Suite Professional** | Response analysis and regex-based sensitive data scanning |\n| **trufflehog** | Secret detection across git repos, filesystems, and cloud storage |\n| **gitleaks** | Git repository scanning for hardcoded secrets |\n| **testssl.sh** | TLS\u002FSSL configuration assessment |\n| **git-dumper** | Downloading exposed .git directories from web servers |\n| **SecretFinder** | JavaScript file analysis for exposed API keys and tokens |\n| **Retire.js** | Detecting JavaScript libraries with known vulnerabilities |\n\n## Common Scenarios\n\n### Scenario 1: API Key in JavaScript Bundle\nThe application's JavaScript bundle contains a hardcoded Google Maps API key and a Stripe publishable key. The Stripe key has overly broad permissions, allowing the attacker to create charges.\n\n### Scenario 2: User API Returns Password Hashes\nThe `\u002Fapi\u002Fusers` endpoint returns complete user objects including bcrypt password hashes. Attackers can extract hashes and attempt offline cracking.\n\n### Scenario 3: PII in Cached API Responses\nThe user profile API endpoint returns full SSN and credit card numbers without masking. The endpoint does not set `Cache-Control: no-store`, so responses are cached in the browser and proxy caches.\n\n### Scenario 4: Git Repository with Database Credentials\nThe `.git` directory is accessible on the production server. Using git-dumper, the attacker downloads the repository history, finding database credentials committed in an early commit that were later \"removed\" but remain in git history.\n\n## Output Format\n\n```\n## Sensitive Data Exposure Assessment Report\n\n**Target**: target.example.com\n**Assessment Date**: 2024-01-15\n**OWASP Category**: A02:2021 - Cryptographic Failures\n\n### Findings Summary\n| Finding | Severity | Data Type |\n|---------|----------|-----------|\n| API keys in JavaScript source | High | Credentials |\n| Password hashes in API response | Critical | Authentication |\n| Unmasked SSN in user profile | Critical | PII |\n| Credit card number in export | High | Financial |\n| .git directory exposed | Critical | Source code + secrets |\n| Missing TLS on API endpoint | High | All data in transit |\n| Sensitive data in error messages | Medium | Technical info |\n\n### Critical: Exposed Secrets\n| Secret Type | Location | Risk |\n|-------------|----------|------|\n| AWS Access Key (AKIA...) | \u002Fstatic\u002Fapp.js line 342 | AWS resource access |\n| Stripe Secret Key (sk_live_...) | .env (via .git exposure) | Payment processing |\n| Database URL with credentials | .git history commit abc123 | Database access |\n| JWT Signing Secret | config.json (via .git) | Token forgery |\n\n### Data Over-Exposure in APIs\n| Endpoint | Unnecessary Fields Returned |\n|----------|-----------------------------|\n| GET \u002Fapi\u002Fusers | password_hash, internal_id, created_ip |\n| GET \u002Fapi\u002Fusers\u002F{id} | ssn, credit_card_full, date_of_birth |\n| GET \u002Fapi\u002Forders | customer_phone, customer_address |\n\n### Recommendation\n1. Remove all hardcoded secrets from client-side code; use backend proxies\n2. Rotate all exposed credentials immediately\n3. Remove .git directory from production web root\n4. Implement response field filtering; return only required fields\n5. Mask sensitive data (SSN, credit card) in all API responses\n6. Add Cache-Control: no-store to all sensitive endpoints\n7. Enable TLS 1.2+ on all endpoints; redirect HTTP to HTTPS\n8. Implement secret scanning in CI\u002FCD pipeline (trufflehog\u002Fgitleaks)\n```\n","# Testing for Sensitive Data Exposure\n\n## When to Use\n\n- During authorized penetration tests when assessing data protection controls\n- When evaluating applications for GDPR, PCI DSS, HIPAA, or other data protection compliance\n- For identifying leaked API keys, credentials, tokens, and secrets in application responses\n- When testing whether sensitive data is properly encrypted in transit and at rest\n- During security assessments of APIs that handle PII, financial data, or health records\n\n## Prerequisites\n\n- **Authorization**: Written penetration testing agreement with data handling scope\n- **Burp Suite Professional**: For intercepting and analyzing responses for sensitive data\n- **trufflehog**: Secret scanning tool (`pip install trufflehog`)\n- **gitleaks**: Git repository secret scanner (`go install github.com\u002Fgitleaks\u002Fgitleaks\u002Fv8@latest`)\n- **curl\u002Fhttpie**: For manual endpoint testing\n- **Browser DevTools**: For examining local storage, session storage, and cached data\n- **testssl.sh**: TLS configuration testing tool\n\n## Workflow\n\n### Step 1: Scan for Secrets in Client-Side Code\n\nSearch JavaScript files, HTML source, and other client-side resources for exposed secrets.\n\n```bash\n# Download and search JavaScript files for secrets\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | \\\n  grep -oP 'src=\"[^\"]*\\.js[^\"]*\"' | \\\n  grep -oP '\"[^\"]*\"' | tr -d '\"' | while read js; do\n    echo \"=== Scanning: $js ===\"\n    # Handle relative URLs\n    if [[ \"$js\" == \u002F* ]]; then\n      curl -s \"https:\u002F\u002Ftarget.example.com$js\"\n    else\n      curl -s \"$js\"\n    fi | grep -inE \\\n      \"(api[_-]?key|apikey|api[_-]?secret|aws[_-]?access|aws[_-]?secret|private[_-]?key|password|secret|token|auth|credential|AKIA[0-9A-Z]{16})\" \\\n      | head -20\ndone\n\n# Search for common secret patterns\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Fstatic\u002Fapp.js\" | grep -nP \\\n  \"(AIza[0-9A-Za-z-_]{35}|AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{48}|ghp_[a-zA-Z0-9]{36}|xox[bpsa]-[0-9a-zA-Z-]{10,})\"\n\n# Check source maps for exposed source code\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Fstatic\u002Fapp.js.map\" | head -c 500\n# Source maps may contain original source code with embedded secrets\n\n# Search HTML source for exposed data\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | grep -inE \\\n  \"(api_key|secret|password|token|private_key|database_url|smtp_password)\" | head -20\n\n# Check for exposed .env or configuration files\nfor file in .env .env.local .env.production config.json settings.json \\\n  .aws\u002Fcredentials .docker\u002Fconfig.json; do\n  status=$(curl -s -o \u002Fdev\u002Fnull -w \"%{http_code}\" \\\n    \"https:\u002F\u002Ftarget.example.com\u002F$file\")\n  if [ \"$status\" == \"200\" ]; then\n    echo \"FOUND: $file ($status)\"\n  fi\ndone\n```\n\n### Step 2: Analyze API Responses for Data Over-Exposure\n\nCheck if API endpoints return more data than necessary.\n\n```bash\n# Fetch user profile and examine response fields\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002Fme\" | jq .\n\n# Look for sensitive fields that should not be exposed:\n# - password, password_hash, password_salt\n# - ssn, social_security_number, national_id\n# - credit_card_number, card_cvv, card_expiry\n# - api_key, secret_key, access_token, refresh_token\n# - internal_id, database_id\n# - ip_address, session_id\n# - date_of_birth, drivers_license\n\n# Check list endpoints for excessive data\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\" | jq '.[0] | keys'\n\n# Compare public vs authenticated responses\necho \"=== Public ===\"\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002F1\" | jq 'keys'\necho \"=== Authenticated ===\"\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002F1\" | jq 'keys'\n\n# Check error responses for information leakage\ncurl -s -X POST \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"invalid\": \"data\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\" | jq .\n# Look for: stack traces, database queries, internal paths, version info\n\n# Test for PII in search\u002Fautocomplete responses\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fsearch?q=john\" | jq .\n# May return full user records instead of just names\n```\n\n### Step 3: Test Data Transmission Security\n\nVerify that sensitive data is encrypted during transmission.\n\n```bash\n# Check TLS configuration\n# Using testssl.sh\n.\u002Ftestssl.sh \"https:\u002F\u002Ftarget.example.com\"\n\n# Quick TLS checks with curl\ncurl -s -v \"https:\u002F\u002Ftarget.example.com\u002F\" 2>&1 | grep -E \"(SSL|TLS|cipher|subject)\"\n\n# Check for HTTP (non-HTTPS) endpoints\ncurl -s -I \"http:\u002F\u002Ftarget.example.com\u002F\" | head -5\n# Should redirect to HTTPS\n\n# Check for mixed content (HTTP resources on HTTPS pages)\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | grep -oP \"http:\u002F\u002F[^\\\"'> ]+\" | head -20\n\n# Check if sensitive forms submit over HTTPS\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | grep -oP 'action=\"[^\"]*\"'\n# Form action should use HTTPS\n\n# Check for sensitive data in URL parameters (query string)\n# URLs are logged in browser history, server logs, proxy logs, Referer headers\n# Look for: \u002Flogin?username=admin&password=secret\n# \u002Fapi\u002Fdata?ssn=123-45-6789\n# \u002Fsearch?credit_card=4111111111111111\n\n# Check WebSocket encryption\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F\" | grep -oP \"(ws|wss):\u002F\u002F[^\\\"'> ]+\"\n# ws:\u002F\u002F is unencrypted; should only use wss:\u002F\u002F\n```\n\n### Step 4: Examine Browser Storage for Sensitive Data\n\nCheck local storage, session storage, cookies, and cached responses.\n\n```bash\n# Check what cookies are set and their security attributes\ncurl -s -I \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | grep -i \"set-cookie\"\n\n# In browser DevTools (Application tab):\n# 1. Local Storage: Check for stored tokens, PII, credentials\n# 2. Session Storage: Check for temporary sensitive data\n# 3. IndexedDB: Check for cached application data\n# 4. Cache Storage: Check for cached API responses containing PII\n# 5. Cookies: Check for sensitive data in cookie values\n\n# Common insecure storage patterns:\n# localStorage.setItem('access_token', 'eyJ...');  \u002F\u002F XSS can steal\n# localStorage.setItem('user', JSON.stringify({email: '...', ssn: '...'}));\n# sessionStorage.setItem('credit_card', '4111...');\n\n# Check for autocomplete on sensitive forms\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | \\\n  grep -oP '\u003Cinput[^>]*(password|credit|ssn|card)[^>]*>' | \\\n  grep -v 'autocomplete=\"off\"'\n# Password and credit card fields should have autocomplete=\"off\"\n\n# Check Cache-Control headers on sensitive pages\nfor page in \u002Faccount\u002Fprofile \u002Fapi\u002Fusers\u002Fme \u002Ftransactions \u002Fbilling; do\n  echo -n \"$page: \"\n  curl -s -I \"https:\u002F\u002Ftarget.example.com$page\" \\\n    -H \"Authorization: Bearer $TOKEN\" | \\\n    grep -i \"cache-control\" | tr -d '\\r'\n  echo\ndone\n# Sensitive pages should have: Cache-Control: no-store\n```\n\n### Step 5: Scan Git Repositories and Source Code for Secrets\n\nSearch for accidentally committed secrets in version control.\n\n```bash\n# Check for exposed .git directory\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F.git\u002Fconfig\"\ncurl -s \"https:\u002F\u002Ftarget.example.com\u002F.git\u002FHEAD\"\n\n# If .git is exposed, use git-dumper to download\n# pip install git-dumper\ngit-dumper https:\u002F\u002Ftarget.example.com\u002F.git \u002Ftmp\u002Ftarget-repo\n\n# Scan downloaded repository with trufflehog\ntrufflehog filesystem \u002Ftmp\u002Ftarget-repo\n\n# Scan with gitleaks\ngitleaks detect --source \u002Ftmp\u002Ftarget-repo -v\n\n# If GitHub\u002FGitLab repository is available (authorized scope)\ntrufflehog github --org target-organization --token $GITHUB_TOKEN\ngitleaks detect --source https:\u002F\u002Fgithub.com\u002Forg\u002Frepo -v\n\n# Common secrets found in repositories:\n# - AWS access keys (AKIA...)\n# - Database connection strings\n# - API keys (Google, Stripe, Twilio, SendGrid)\n# - Private SSH keys\n# - JWT signing secrets\n# - OAuth client secrets\n# - SMTP credentials\n\n# Search for secrets in Docker images\n# docker save target-image:latest | tar x -C \u002Ftmp\u002Fdocker-layers\n# Search each layer for credentials\n```\n\n### Step 6: Test Data Masking and Redaction\n\nVerify that sensitive data is properly masked in the application.\n\n```bash\n# Check if credit card numbers are fully displayed\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fpayment-methods\" | jq .\n# Should show: **** **** **** 4242, not full number\n\n# Check if SSN\u002Fnational ID is masked\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002Fme\" | jq '.ssn'\n# Should show: ***-**-6789, not full SSN\n\n# Check API responses for password hashes\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\" | jq '.[].password \u002F\u002F empty'\n# Should return nothing; password hashes should never be in API responses\n\n# Check export\u002Fdownload features for unmasked data\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fusers\u002Fexport?format=csv\" | head -5\n# CSV exports often contain unmasked PII\n\n# Check logging endpoints for sensitive data\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fadmin\u002Flogs\" | \\\n  grep -iE \"(password|token|secret|credit_card|ssn)\" | head -10\n# Logs should not contain sensitive data in plaintext\n\n# Test for sensitive data in error messages\ncurl -s -X POST \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"email\":\"duplicate@test.com\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fregister\"\n# Should not reveal: \"User with email duplicate@test.com already exists\"\n# Should show: \"Registration failed\" (generic)\n```\n\n## Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| **Sensitive Data Exposure** | Unintended disclosure of PII, credentials, financial data, or health records |\n| **Data Over-Exposure** | API returning more data fields than the client needs |\n| **Secret Leakage** | API keys, tokens, or credentials exposed in client-side code or logs |\n| **Data at Rest** | Sensitive data stored in databases, files, or backups without encryption |\n| **Data in Transit** | Sensitive data transmitted over network without TLS encryption |\n| **Data Masking** | Replacing sensitive data with redacted values (e.g., showing last 4 digits of credit card) |\n| **PII** | Personally Identifiable Information - data that can identify an individual |\n| **Information Leakage** | Excessive error messages, stack traces, or debug information in responses |\n\n## Tools & Systems\n\n| Tool | Purpose |\n|------|---------|\n| **Burp Suite Professional** | Response analysis and regex-based sensitive data scanning |\n| **trufflehog** | Secret detection across git repos, filesystems, and cloud storage |\n| **gitleaks** | Git repository scanning for hardcoded secrets |\n| **testssl.sh** | TLS\u002FSSL configuration assessment |\n| **git-dumper** | Downloading exposed .git directories from web servers |\n| **SecretFinder** | JavaScript file analysis for exposed API keys and tokens |\n| **Retire.js** | Detecting JavaScript libraries with known vulnerabilities |\n\n## Common Scenarios\n\n### Scenario 1: API Key in JavaScript Bundle\nThe application's JavaScript bundle contains a hardcoded Google Maps API key and a Stripe publishable key. The Stripe key has overly broad permissions, allowing the attacker to create charges.\n\n### Scenario 2: User API Returns Password Hashes\nThe `\u002Fapi\u002Fusers` endpoint returns complete user objects including bcrypt password hashes. Attackers can extract hashes and attempt offline cracking.\n\n### Scenario 3: PII in Cached API Responses\nThe user profile API endpoint returns full SSN and credit card numbers without masking. The endpoint does not set `Cache-Control: no-store`, so responses are cached in the browser and proxy caches.\n\n### Scenario 4: Git Repository with Database Credentials\nThe `.git` directory is accessible on the production server. Using git-dumper, the attacker downloads the repository history, finding database credentials committed in an early commit that were later \"removed\" but remain in git history.\n\n## Output Format\n\n```\n## Sensitive Data Exposure Assessment Report\n\n**Target**: target.example.com\n**Assessment Date**: 2024-01-15\n**OWASP Category**: A02:2021 - Cryptographic Failures\n\n### Findings Summary\n| Finding | Severity | Data Type |\n|---------|----------|-----------|\n| API keys in JavaScript source | High | Credentials |\n| Password hashes in API response | Critical | Authentication |\n| Unmasked SSN in user profile | Critical | PII |\n| Credit card number in export | High | Financial |\n| .git directory exposed | Critical | Source code + secrets |\n| Missing TLS on API endpoint | High | All data in transit |\n| Sensitive data in error messages | Medium | Technical info |\n\n### Critical: Exposed Secrets\n| Secret Type | Location | Risk |\n|-------------|----------|------|\n| AWS Access Key (AKIA...) | \u002Fstatic\u002Fapp.js line 342 | AWS resource access |\n| Stripe Secret Key (sk_live_...) | .env (via .git exposure) | Payment processing |\n| Database URL with credentials | .git history commit abc123 | Database access |\n| JWT Signing Secret | config.json (via .git) | Token forgery |\n\n### Data Over-Exposure in APIs\n| Endpoint | Unnecessary Fields Returned |\n|----------|-----------------------------|\n| GET \u002Fapi\u002Fusers | password_hash, internal_id, created_ip |\n| GET \u002Fapi\u002Fusers\u002F{id} | ssn, credit_card_full, date_of_birth |\n| GET \u002Fapi\u002Forders | customer_phone, customer_address |\n\n### Recommendation\n1. Remove all hardcoded secrets from client-side code; use backend proxies\n2. Rotate all exposed credentials immediately\n3. Remove .git directory from production web root\n4. Implement response field filtering; return only required fields\n5. Mask sensitive data (SSN, credit card) in all API responses\n6. Add Cache-Control: no-store to all sensitive endpoints\n7. Enable TLS 1.2+ on all endpoints; redirect HTTP to HTTPS\n8. Implement secret scanning in CI\u002FCD pipeline (trufflehog\u002Fgitleaks)\n```\n",{"name":5,"tags":63,"author":65,"domain":56,"license":15,"version":66,"nist_csf":67,"subdomain":50,"description":7,"nist_ai_rmf":72,"mitre_attack":76,"atlas_techniques":81},[64,49,45,51,48,46,42],"penetration-testing","mahipal","1.0",[68,69,70,71],"PR.PS-01","ID.RA-01","PR.DS-10","DE.CM-01",[73,74,75],"MEASURE-2.7","MAP-5.1","MANAGE-2.4",[77,78,79,80],"T1190","T1059.007","T1505.003","T1083",[82,83,84],"AML.T0070","AML.T0066","AML.T0082","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Ftesting-for-sensitive-data-exposure",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":96,"prompt":106,"zipAvailable":107},[97,100,103],{"tool":98,"command":99},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill testing-for-sensitive-data-exposure",{"tool":101,"command":102},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill testing-for-sensitive-data-exposure",{"tool":104,"command":105},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill testing-for-sensitive-data-exposure","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-sensitive-data-exposure\u002FSKILL.md",true,[109,114,120],{"path":110,"resourceType":110,"resourceTypeDesc":111,"sizeBytes":112,"sourceHtmlUrl":113},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-sensitive-data-exposure\u002FLICENSE",{"path":115,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fapi-reference.md","REFERENCE","参考文档",1740,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-sensitive-data-exposure\u002Freferences\u002Fapi-reference.md",{"path":121,"resourceType":122,"resourceTypeDesc":123,"sizeBytes":124,"sourceHtmlUrl":125},"scripts\u002Fagent.py","SCRIPT","脚本",9726,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-sensitive-data-exposure\u002Fscripts\u002Fagent.py",[127,152,175,200,225,250],{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":134,"publishedAt":58},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[133],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[135,136,137,138,57,56,139,140,52,141,142,143,144,145,146,147,148,149,150,151],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":58},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[158],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[160,148,161,162,57,163,56,52,164,165,166,167,168,169,170,42,171,172,173,174],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":183,"publishedAt":58},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[181,182],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[170,184,185,186,40,56,187,188,164,189,190,191,192,193,194,195,196,197,198,199],"backup","recovery","validating backup integrity for recovery","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":207,"publishedAt":58},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[206],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[208,209,210,56,211,212,213,214,215,216,217,39,218,219,220,221,167,222,223,224],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":226,"name":227,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":229,"categories":230,"keywords":232,"publishedAt":58},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[231],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[55,233,234,56,235,236,237,238,239,240,241,242,243,244,245,246,43,247,248,249],"framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","prioritization","ssvc","decision-tree",{"skillNo":251,"name":252,"nameZh":6,"description":253,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":254,"categories":255,"keywords":257,"publishedAt":58},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[256],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[57,258,56,259,260,261,262,263,264,265,266,195,267,196,268,269,270,271,272,273],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]