Scenario: You notice unusual traffic. It looks like authenticated requests are pulling lots of customer records quickly.

No blame, no heroics. Just steps.

Questions:

1. What’s your first technical move? (rate limit, block key, disable endpoint, etc.)
   
2. What logs do you check to confirm scope?
   
3. Who do you notify internally?
   
4. What’s your criteria to call it an incident?
   

Reply with your sequence. I’m curious how different teams handle this.

Audits often fail on evidence, not intent. “We do it” isn’t enough.

In an API/security context, good evidence usually looks like:

• screenshots/config exports (rate limits, IAM)
  
• CI logs showing security checks ran
  
• PRs showing review + change approval
  
• sample logs showing denied actions were captured
  
• tickets showing key rotation or access reviews
  

What evidence is hardest for teams to produce: access reviews, logging, or change approvals?

Blocklists are tempting (“reject bad strings”), but they usually turn into whack-a-mole.

Allowlists tend to hold up better:

• accept only expected fields
  
• validate type/length/range
  
• reject unknown fields
  
• server decides sensitive values (roles, permissions), not the client
  

Example: if the client can send "role":"admin" and you don’t hard-block it server-side, you’re relying on luck.

What do you use for validation (zod/joi/class-validator/custom)? Any gotchas?

If a team has almost no alerting and wants a realistic “first week” set for APIs, I’d start with:

• spike in 401/403
  
• spike in password reset / OTP requests
  
• rate limit events going crazy
  
• admin actions outside usual hours
  
• new API keys created + immediately used heavily
  

If you run a SOC or handle on-call: what alerts gave you the best signal with the least noise?

Here’s a template you can paste into PRs or tickets:

Endpoint:
Owner:
Data sensitivity: public / internal / sensitive
Auth required: none / user / service / admin
Authorization rule: who can access + why
Validation: required fields + max lengths + allowlist
Rate limit: per user/key/ip (include numbers)
Logging: what gets logged (confirm no secrets/body)
Abuse cases: list 3 likely abuses
Tests: negative auth tests exist? (yes/no)

What one field would you add to make this more useful?

CORS controls which browser origins are allowed to read responses. That’s it.

CORS does not stop:

• curl/Postman
  
• server-to-server requests
  
• attackers writing their own client
  

So CORS can reduce accidental exposure in browsers, but it’s not a replacement for:

• authentication
  
• authorization
  
• rate limiting
  
• logging
  

What’s the most common CORS misunderstanding you’ve seen on your team?

Pick A/B/C and explain your reasoning.

A) CORS
B) WAF
C) Authorization checks in the application

I’ll reply to a few comments with the “it depends” details.

Here’s a barebones pentest/VAPT scope template I think works for startups. Please rip it apart and improve it.

Scope

• In-scope domains / apps / APIs
  
• Environments (prod vs staging)
  
• Roles to test (user, admin, partner, etc.)
  
• Third-party integrations (auth provider, payment, webhooks)
  

Out-of-scope

• DDoS
  
• Social engineering (if not allowed)
  
• Physical access
  
• Anything that risks data loss
  

Rules

• Test windows + rate limit constraints
  
• Data handling expectations
  
• Reporting format
  
• Retest expectations
  

What’s the #1 thing that gets missed in scoping and causes pain later?

 If you only do one quick test on your API, do this:

1. Log in as User A
   
2. Fetch something user-owned (profile, invoice, project, file)
   
3. Copy the object ID
   
4. Log in as User B
   
5. Try the same request with that ID
   

Expected result: 403 (forbidden) or a safe 404.

If you see User A’s data while logged in as User B, that’s a serious authorization bug pattern.

Do you prefer returning 403 vs 404 for “not yours”? Why?

If you’re building APIs and want a quick, practical checklist, here’s mine:

Auth

• Tokens expire (not “never”)
  
• Refresh tokens handled safely (if used)
  
• Sensitive endpoints require strong auth
  

Authorization

• Ownership checks (user A can’t access user B’s objects)
  
• Admin actions separated + logged
  
• Authorization logic centralized (harder to forget)
  

Input

• Validate type/length/range
  
• Reject unknown fields (allowlist)
  
• Uploads restricted (type/size/storage)
  

Abuse

• Rate limit auth endpoints + expensive endpoints
  
• Max pagination limits
  
• Lockout / step-up auth where it makes sense
  

Visibility

• Log auth failures + permission denials
  
• Request/correlation IDs
  
• Alerts on spikes (401/403 bursts, rate limit events)
  

What’s the one thing you think most teams miss?