SECURE/VIBE

Field guide 2026 Open reference

A practical field guide to AI-assisted development

Secure Vibe Coding

From AI-generated code to secure software.

AI makes it easier than ever to build applications. But code that runs is not necessarily code that is safe.

Learn how to recognize common security flaws, guide AI toward secure implementations, audit your codebase with free tools, and verify that your fixes actually work.

Read the vulnerability handbookJump to the audit checklist

Built for developers, cybersecurity learners, and AI-assisted builders.

One missing condition
note = db.query(Note).filter(    Note.id == note_id    Note.id == note_id,    Note.owner_id == user.id).first()

The feature works either way. Only one version stops Account B from reading Account A's notes.

Why secure vibe coding matters

Vibe coding makes software development faster by allowing developers to describe what they want and let an AI coding assistant generate much of the implementation.

That speed is useful. It also creates a new challenge: developers can end up shipping code they have not fully understood, reviewed, or tested.

An AI-generated application might have a polished interface, a working login page, a connected database, and all the expected features, while still allowing users to access other people's records or exposing privileged credentials.

The problem is not simply that AI generates bad code. The problem is that functional correctness and security correctness are different things.

A feature can work exactly as requested and still violate a security requirement that was never specified.

The four principles of secure vibe coding

  1. 01

    Understand

    Know what the code does, what it trusts, and which resources it protects.

  2. 02

    Detect

    Use code analysis, dependency scanners, secret detection, and security tests.

  3. 03

    Fix

    Use established libraries, secure defaults, least privilege, and explicit authorization.

  4. 04

    Verify

    Retest the original failure and add regression tests to prevent it from returning.

The objective isn't to stop using AI. It's to make security a normal part of using AI.

01Vulnerability handbook

Common vulnerabilities in AI-generated code

AI can write code that looks professional and still miss important security properties. Each entry below covers what the flaw is, how to detect it, how to fix it, and where to learn more.

01High priority

Broken access control: IDOR and BOLA

The server checks who you are, but not what you may touch.

What it is

Broken access control occurs when an application fails to enforce what a user is allowed to do. IDOR, or Insecure Direct Object Reference, is a common example. BOLA, or Broken Object Level Authorization, is the API security term for a related class of flaw.

Imagine an application where a user can retrieve a note using /api/notes/501. If changing the identifier to 502 returns somebody else's note, the server may be authenticating users without checking their permissions on the requested object.

Why AI makes it easy

The implementation may check that a user is logged in but forget to check ownership. It may also rely on hidden buttons, frontend route guards, or user IDs supplied by the client.

How to detect it

  • Create two test accounts with separate data.
  • Try accessing Account A's records while authenticated as Account B.
  • Check read, update, delete, export, and other sensitive operations.
  • Review whether authorization is enforced in the backend.

How to fix it

  • Enforce authorization on the server for every protected operation.
  • Scope database queries to the authenticated user's permitted records.
  • Check tenant membership and resource ownership where applicable.
  • Add negative tests proving that unauthorized requests fail.

Further reading

02

Injection: SQL, command injection, and XSS

Untrusted data changes the meaning of a query, command, or page.

What it is

Injection occurs when untrusted data changes the meaning of a query, command, or executable content. SQL injection can alter database operations, command injection can affect operating-system commands, and cross-site scripting (XSS) can cause malicious browser-side code to execute.

VulnerableAn insecure pattern
query = "SELECT * FROM users WHERE name = '" + name + "'"

This constructs SQL by concatenating user input.

SaferA safer pattern
cursor.execute(
    "SELECT * FROM users WHERE name = ?",
    (name,)
)

The placeholder syntax varies by database driver. Use the parameterized-query API supported by your database library.

How to detect it

  • Look for dynamically constructed SQL and shell commands.
  • Search for unsafe rendering of untrusted HTML.
  • Use static analysis and test inputs in an authorized lab.
  • Review whether the framework's safe APIs are being used correctly.

How to fix it

  • Use parameterized queries.
  • Avoid shell execution where possible.
  • Use context-appropriate output encoding and safe DOM APIs.
  • Treat validation as an additional layer, not a replacement for safe query construction.

Further reading

03

Hardcoded secrets and exposed credentials

A privileged key ends up in a bundle, a repository, or its history.

What it is

Secrets include API tokens, private keys, database passwords, signing keys, and service credentials. If privileged secrets are embedded in frontend bundles or committed to a repository, other people may be able to use them.

VulnerableAn insecure pattern
const API_KEY = "real-production-secret";

Putting a secret in a frontend environment variable does not make it private if the build process embeds it in browser-accessible code.

How to detect it

  • Scan the repository using Gitleaks or Trivy.
  • Inspect frontend build output for privileged credentials.
  • Check Git history when a secret has previously been committed.
  • Review permissions granted to service keys.

How to fix it

  • Store secrets in an appropriate server-side configuration or secrets manager.
  • Use least-privilege credentials.
  • Rotate credentials that may have been exposed.
  • Use safe placeholders in examples and documentation.

Further reading

04

Authentication and session mistakes

Identity, session handling, and authorization get blurred together.

What it is

Authentication establishes who a user is. Session management and token validation maintain that identity across requests. Authorization determines what that identity may do.

These are related but separate security responsibilities.

Common mistakes

  • Trusting a role stored only in frontend state.
  • Accepting JWTs without verifying their signatures and required claims.
  • Storing passwords using fast general-purpose hashes instead of suitable password-hashing algorithms.
  • Omitting rate limits on login and OTP verification.
  • Misconfiguring cookie security or session expiration.

How to detect it

  • Review login, logout, token issuance, refresh, and expiration flows.
  • Test unauthenticated and unauthorized requests separately.
  • Verify JWT signature, issuer, audience, expiration, and allowed algorithms as appropriate to the application.
  • Check password hashing and session-cookie configuration.

How to fix it

Prefer maintained authentication libraries and established identity providers. Keep authorization checks separate from token validation, protect sessions, and add rate limiting where needed.

Further reading

05

Security misconfiguration and error handling

Correct logic, exposed through unsafe defaults and verbose errors.

What it is

An application may have correct business logic but still expose unnecessary information or access through insecure configuration.

Examples include production debug mode, overly permissive CORS, default credentials, verbose stack traces, or excessive service permissions.

How to detect it

  • Review production environment settings.
  • Inspect response headers and error responses.
  • Check CORS allowlists, database privileges, and debug settings.
  • Scan supported configuration files with a tool such as Trivy.

How to fix it

Use secure production defaults, restrict cross-origin access to required origins, return safe external errors, and keep diagnostic details in protected logs.

Further reading

06

Vulnerable dependencies and supply-chain risks

A package you did not write becomes part of your attack surface.

What it is

Modern applications depend on third-party libraries, build tools, plugins, and packages. A vulnerable or compromised dependency can introduce risk even if the application's own code looks reasonable.

How to detect it

  • Run a dependency vulnerability scan.
  • Inspect package manifests and lockfiles.
  • Review newly suggested packages before installing them.
  • Check package provenance and advisories when appropriate.

How to fix it

Use maintained packages, commit lockfiles, update vulnerable dependencies to appropriate fixed versions, remove unnecessary packages, and investigate breaking changes before upgrading.

Further reading

07

Unsafe file uploads and server-side request forgery

The server trusts a file, a path, or a URL that a user controls.

What it is

File upload flaws arise when applications trust user-controlled files or paths too much. Server-side request forgery (SSRF) occurs when an attacker can influence requests made by the server to unintended destinations.

Common mistakes

  • Trusting a filename extension without checking the content.
  • Accepting arbitrary URLs and fetching them from the server.
  • Allowing users to control filesystem paths.
  • Storing uploads in executable public directories.

How to detect it

Review upload handlers, URL-fetching features, path construction, file-size limits, and outbound network access. Test in a local or explicitly authorized environment.

How to fix it

Use allowlists, validate content server-side, generate safe filenames, constrain storage, enforce size limits, and restrict outbound network access to appropriate destinations.

Further reading

08

Missing security tests and insecure business logic

The feature passes its tests but breaks when used out of order.

What it is

A feature can pass normal tests but fail when a user skips a workflow step, changes an object identifier, repeats a request, or performs an action in an unexpected order.

Examples include trusting the client to confirm payment, allowing repeated coupon redemption, or skipping a required approval step.

How to detect it

  • Test unauthorized actions and unexpected state transitions.
  • Check whether payment and approval states are confirmed server-side.
  • Test duplicate requests and relevant race conditions.
  • Review whether tests cover failures, not just successful outcomes.

How to fix it

Enforce critical business rules on the server, validate state transitions, use appropriate database transactions and idempotency controls, and add regression tests for discovered vulnerabilities.

Further reading

OWASP Top 10:2025 categories

The handbook entries above map to the official 2025 list. Use the OWASP Top 10 as an awareness resource, not as a complete checklist.

  1. 01Broken access control
  2. 02Security misconfiguration
  3. 03Software supply-chain failures
  4. 04Cryptographic failures
  5. 05Injection
  6. 06Insecure design
  7. 07Authentication failures
  8. 08Software or data integrity failures
  9. 09Security logging and alerting failures
  10. 10Mishandling of exceptional conditions

Read the official OWASP Top 10(opens in a new tab)

02Hands-on lab

Audit and fix a broken-access-control bug

Use a small local application you own, or a deliberately vulnerable practice app. Do not test systems you do not own or have explicit permission to assess.

Step 1: Review the vulnerable endpoint

The endpoint authenticates the caller with get_current_user, but the query never uses the user. Any authenticated account can read any note by guessing its identifier.

Vulnerablenotes.py
@app.get("/notes/{note_id}")
def get_note(
    note_id: int,
    user=Depends(get_current_user)
):
    note = db.query(Note).filter(
        Note.id == note_id
    ).first()
    if not note:
        raise HTTPException(status_code=404)
    return note

Step 2: Ask AI for a review, not just a patch

A prompt that asks for analysis, a minimal fix, and tests produces a more reliable result than one that only says "fix the security."

Prompt
Review this endpoint for broken object-level authorization. Identify the trust boundary, explain whether the authenticated user can access another user's records, implement the smallest appropriate fix, and write regression tests for both authorized and unauthorized access. Do not claim the fix works unless the tests have actually been run.

Step 3: Apply the fix

The query is now scoped to the authenticated user. A note that the user does not own is indistinguishable from one that does not exist.

Safernotes.py
@app.get("/notes/{note_id}")
def get_note(
    note_id: int,
    user=Depends(get_current_user)
):
    note = db.query(Note).filter(
        Note.id == note_id,
        Note.owner_id == user.id
    ).first()
    if not note:
        raise HTTPException(status_code=404)
    return note

Step 4: Prove it with tests

Add a regression test for each row. The cross-user case is the one that protects you from this bug returning.

Authorization regression tests
TestExpected result
Account A requests its own noteAllowed
Account B requests its own noteAllowed
Account B requests Account A's noteDenied
Unauthenticated client requests a noteDenied
Interactive Threat Fusion Core (Metaballs Physics)
ISOLATED
Hover or drag orbs to fuse exploit paths

Security Principle: In AI-generated code, isolated vulnerabilities (e.g. missing owner check) become catastrophic when fluidly chained with user-controlled input.

03Tools

Free tools to audit your code

No single scanner covers every risk. Use several, understand what each one looks at, and treat findings as leads to investigate.

8-Bit Security Arcade & Retro Terminal
Sprite v1.0
DAEMON://NEURAL_SHIELD_VIBE

> 8-BIT GUARDIAN READY

Retro pixel-art shader test for cybersecurity telemetry.

What scans can and cannot tell you

A clean report means the tool found nothing it knows how to look for. It does not mean the application is secure.

Scanner coverage and limits
ToolUseful forDoes not prove
SemgrepRisky source-code patternsThat business logic is correct
TrivyDependency, secret, and configuration findingsThat every dependency or configuration risk is covered
GitleaksPotential secrets in GitThat every secret has been detected
ZAPIssues observable in a running applicationThat all routes, roles, and business logic are secure
CodeQLCertain deeper code-flow vulnerabilitiesThat all vulnerability classes are absent
BanditCommon Python security patternsThat a Python application is secure overall

A sensible order of operations

  1. 01

    Run source-code and secret scans first.

  2. 02

    Inspect dependency and configuration findings.

  3. 03

    Test the running application.

  4. 04

    Manually verify sensitive authorization and business-logic paths.

04Frameworks

Security standards that give AI testable requirements

"Make it secure" is not a requirement. Standards turn a vague goal into specific items that can be checked.

A secure development lifecycle, in short

AI assistance changes how code is written. It does not remove the need for any of these phases.

  1. 01

    Requirements

    Define users, permissions, sensitive data, and security expectations.

  2. 02

    Design

    Identify trust boundaries and threat scenarios.

  3. 03

    Implementation

    Use secure APIs and least privilege.

  4. 04

    Verification

    Review code, test security properties, and run scanners.

  5. 05

    Deployment

    Apply secure configuration and protect secrets.

  6. 06

    Maintenance

    Patch dependencies, investigate findings, and add regression tests.

05AI Rules & Protocols

Evidence-Integrity Protocol & AI Rules

Prevent superficial agreement, fabricated verification, and silent risk acceptance. Use the interactive workflow to audit permissions, or copy the complete protocol directly into your AI assistant's system prompt.

SECURE FROM COMMIT ZERO

No Yes-Man / Evidence-Integrity Framework

Replaces superficial AI agreement with rigorous, evidence-based security engineering, explicit operating modes, and 8 staged approval gates.

Status: [VERIFIED]

1. Operating Modes

Default: Mode A (Planning)
Active Posture: Read-only inspection & threat modeling
Do not modify application code, configuration, infrastructure, CI/CD, dependencies, tests, or artifacts. Completion of planning does not authorize implementation.
Permitted Activities:
  • Inspecting authorized source code and documentation
  • Identifying assets, trust boundaries, attack surfaces, and security requirements
  • Evaluating architecture, configurations, and dependency manifests
  • Developing threat model, risk register, remediation plan, and test strategy
  • Proposing changes and detailing trade-offs
Mandatory Deliverables:
  • Confirmed task scope & constraints
  • Current-state findings supported by evidence
  • Security requirements & unresolved questions
  • Threat model & risk register
  • Proposed architecture or remediation options
  • Implementation plan with dependencies & approval gates
  • Verification and acceptance criteria

2. Staged Execution & Approval Gates

Follow stages sequentially
STAGE 0:
Scope & Authorization

Establish boundaries before touching code

Requires Explicit Approval

Determine authorized repositories, files, operating mode, permitted tools, and actions requiring explicit human sign-off.

Required Evidence / Deliverables:
Authorized repos/filesOperating mode selectionExcluded targets/actionsTool permissions

3. Evidence Integrity Labels

Every material finding, assumption, and requirement must be tagged with verifiable evidence:

[VERIFIED]Directly supported by inspected source code, reproducible test results, authoritative documentation, configuration, or other relevant evidence.
[OBSERVED]Directly observed, but not necessarily sufficient to establish the broader conclusion.
[INFERRED]A reasoned conclusion based on identified evidence.
[ASSUMPTION]A proposition currently accepted for analysis but not verified.
[UNVERIFIED]A claim that has not been independently established.
[CONTRADICTED]Evidence conflicts with the claim or assumption.
[BLOCKED]Verification or implementation cannot proceed because of a missing prerequisite, permission, dependency, or other constraint.

4. Consistent Risk Formula

Material security risks must use qualitative evidence rather than invented numbers:

Risk Score = Likelihood (1–5) × Impact (1–5)
Score 1–4 (Low)Routine controls
Score 5–9 (Moderate)Documented justification
Score 10–16 (High)Escalate & verify
Score 17–25 (Critical)Urgent containment
Confidence is independent: High, Medium, or Low confidence must be reported separately from severity. Never downgrade an unverified critical risk to low!

06Audit checklist

A pre-release security checklist

Work through this before you ship. Progress is kept on this page only and resets when you reload.

0 / 15 complete
Access control
Input and output
Authentication and secrets
Dependencies and configuration
Verification

07Reading room

Where to go next

A short, staged reading list. Each item is a primary source from the team that maintains the material.

Level 1

Build the fundamentals

Start here if you are new to application security.
Level 2

Learn to verify security

Level 3

Practice hands-on

08Secure loop

The secure vibe coding loop

Security is not a final gate. It is a loop you run on every feature, and the output of each pass feeds the next.

  1. 01

    Define security requirements

    Identify users, data, trust boundaries, and permissions.

  2. 02

    Generate and review code

    Use AI rules and inspect the changes it proposes.

  3. 03

    Test security properties

    Check unauthorized access, invalid inputs, and failure paths.

  4. 04

    Run security scanners

    Check source code, dependencies, secrets, and the running application.

  5. 05

    Fix and retest

    Verify the original issue is resolved and add a regression test.

Then repeat for the next feature. Every fixed vulnerability should leave behind a test that keeps it fixed.