Security Encyclopedia

Users can act outside their intended permissions, accessing other users' data or admin functionality without proper authorization checks.

Sensitive data is exposed due to weak or missing encryption — using outdated algorithms like MD5/SHA1, storing passwords in plaintext, or transmitting data without TLS.

Your application inherits vulnerabilities from third-party dependencies — outdated packages with known CVEs that attackers actively exploit.

Default configurations, open CORS policies, debug mode in production, or verbose error messages expose your application to attackers.

Attacker inserts malicious code into queries or commands by exploiting unsanitized user input — SQL injection, NoSQL injection, and OS command injection.

The application's architecture has fundamental security flaws — business logic on the client side, missing server-side validation, or no threat modeling.

Weak authentication mechanisms allow attackers to compromise passwords, keys, or session tokens — JWT without expiration, tokens stored in localStorage, or missing MFA.

Applications that don't verify the integrity of data, software updates, or CI/CD pipelines are vulnerable to tampering — insecure deserialization and unsigned updates.

Missing or insufficient logging of security events like failed logins, access violations, and data changes makes it impossible to detect and respond to attacks.

Attacker tricks the server into making requests to internal resources — accessing cloud metadata, internal APIs, or services that should not be publicly reachable.

Hardcoded API keys, passwords, or tokens directly in mobile app source code — easily extracted by decompiling the app bundle.

Vulnerable SDKs, outdated native libraries, or compromised third-party modules in your mobile app introduce security risks from your dependencies.

Mobile apps with weak authentication — storing sessions insecurely, missing token refresh, or authorization checks only on the client side.

Mobile apps that don't validate user input or sanitize output are vulnerable to injection attacks, data corruption, and unexpected behavior.

Mobile app transmits sensitive data over HTTP instead of HTTPS, or accepts invalid SSL certificates — enabling man-in-the-middle attacks on public WiFi.

Mobile app collects, stores, or transmits personally identifiable information (PII) without proper consent, encryption, or data minimization practices.

Mobile app lacks code obfuscation, anti-tampering, or anti-debugging protections — making it easy to reverse engineer, modify, and redistribute.

Mobile app ships with debug mode enabled, excessive permissions, exported activities, or backup allowed — exposing data and functionality to other apps.

Sensitive data like tokens, passwords, or personal information stored in plaintext on the device — in AsyncStorage, SharedPreferences, or local databases without encryption.

Mobile app uses weak encryption algorithms, hardcoded keys, or implements custom cryptography — making encrypted data effectively unprotected.

API endpoints don't verify that the requesting user owns the resource they're accessing — allowing attackers to access other users' data by changing object IDs.

API authentication mechanisms are weak or improperly implemented — JWT without proper validation, tokens not in httpOnly cookies, or missing token expiration.

API allows users to read or modify object properties they shouldn't have access to — mass assignment, excessive data exposure, or missing field-level access control.

API endpoints without rate limiting, pagination, or resource limits — allowing attackers to exhaust server resources, rack up costs, or extract large datasets.

Admin or privileged API endpoints accessible to regular users — missing role checks allow privilege escalation to administrative functions.

Business-critical flows like registration, password reset, or purchase lack bot protection such as CAPTCHA, rate limiting, or device fingerprinting.

The API fetches a URL provided by the user without validation, allowing attackers to probe internal services, cloud metadata endpoints, or private networks.

APIs expose excessive information through open CORS policies, verbose error messages, missing security headers, or default configurations that were never hardened.

Multiple API versions remain active without documentation or deprecation, leaving old endpoints with known vulnerabilities accessible to attackers.

Your API blindly trusts responses from third-party APIs without validation, allowing attackers to exploit upstream services to compromise your application.

Supabase tables without RLS enabled allow any authenticated or anonymous user to read, insert, update, and delete all rows using the client library.

RLS policies that use USING(true) or WITH CHECK(true) effectively disable row-level security by allowing all operations for all users.

RLS is enabled on a table but no policies are defined, which silently blocks all access including legitimate queries from your application.

The Supabase service_role key is hardcoded in frontend code, committed to a repository, or exposed in client bundles, granting full database admin access to anyone.

Supabase storage buckets with overly permissive policies allow any user to upload, read, or delete files including other users' private documents and images.

Supabase database functions (RPC) callable from the client without checking auth.uid(), allowing anonymous users to execute privileged operations.

The anon database role has been granted permissions on too many tables, expanding the attack surface for anyone with the publicly available anon key.

Database schema changes are applied manually through the Supabase Dashboard instead of tracked migration files, making security audits and rollbacks impossible.

Firestore security rules set to 'allow read, write: if true' give any user — authenticated or not — full access to read, create, modify, and delete all documents.

Firebase Realtime Database rules set '.read: true' and '.write: true' at the root level, allowing anyone on the internet to read and modify all data.

Firebase Cloud Storage rules allow any user to read, write, or delete files without authentication, exposing uploaded content and enabling file tampering.

Parent-level Firebase rules override restrictive child rules, unintentionally granting broader access than intended to nested collections and documents.

Firebase configuration (apiKey, projectId, databaseURL) is hardcoded in JavaScript bundles and publicly accessible, enabling attackers to interact with your Firebase services.

Firebase Authentication allows sign-up without email verification, enabling attackers to create unlimited accounts and abuse authenticated-only features.

Firebase Cloud Functions exposed as HTTP endpoints accept and process requests without verifying authentication tokens or validating input data.

Using React's dangerouslySetInnerHTML with unsanitized user input allows attackers to inject malicious scripts that execute in other users' browsers.

Storing JWT tokens, session tokens, or API keys in localStorage makes them accessible to any JavaScript running on the page, including XSS payloads.

Next.js page props passed through getServerSideProps or getStaticProps leak sensitive data like API keys, database URLs, or internal configuration via the __NEXT_DATA__ script tag.

JavaScript source map files (.map) are publicly accessible in production, revealing the complete original source code including comments, variable names, and internal logic.

Next.js API routes configured with Access-Control-Allow-Origin: * allow any website to make authenticated cross-origin requests, enabling CSRF-like attacks.

Server Actions called from malicious third-party sites without origin validation, letting attackers trigger state-changing requests on behalf of logged-in users.

A critical vulnerability in Next.js versions before 15.2.3 allows attackers to bypass middleware-based auth checks entirely by sending a crafted internal header.

API keys, tokens, or secrets written directly in source code, making them visible to anyone with repo access — including public GitHub repositories.

User-supplied data sent directly to databases or external APIs without any type, format, or content validation.

User passwords stored as raw strings in the database instead of being hashed with a proper algorithm like bcrypt or Argon2.

JWTs signed without an `exp` claim that never expire, meaning a stolen token grants permanent access with no way to revoke it.

Showing or hiding UI elements based on user role in React, without any server-side enforcement — easily bypassed by anyone who opens DevTools.

API routes that perform sensitive operations — reading user data, modifying records, deleting resources — with no session or token verification.

Detailed error messages, stack traces, or internal paths sent to the client or logged publicly, giving attackers a map of your application internals.

npm packages or other dependencies with published security vulnerabilities (CVEs) that haven't been updated, leaving known attack vectors open in your app.

Passing user-controlled data to eval(), new Function(), or similar dynamic code execution functions, enabling arbitrary code execution on your server.

A .env file containing real credentials committed to git, making all secrets permanently accessible to anyone with repo access — including through git history.

The Content-Security-Policy (CSP) header is absent, leaving browsers without instructions on which sources of scripts, styles, and resources to trust.

The X-Frame-Options header is absent, allowing attackers to embed your app in an invisible iframe and trick users into clicking your UI elements (clickjacking).

The X-Content-Type-Options: nosniff header is absent, allowing browsers to guess (sniff) the content type of a response and potentially execute content as script.

The Strict-Transport-Security header is absent, allowing browsers to connect over plain HTTP and enabling downgrade attacks where an attacker intercepts unencrypted traffic.

Session cookies set without the Secure flag, allowing them to be transmitted over unencrypted HTTP connections and intercepted by attackers on the network.

Session or auth cookies accessible to JavaScript via document.cookie, enabling XSS attacks to steal session tokens directly from the browser.

Cookies missing the SameSite attribute (or set to None without Secure), enabling cross-site request forgery by allowing cookies to be sent with cross-origin requests.

Server accepting obsolete TLS versions (TLS 1.0, TLS 1.1) or weak cipher suites, enabling downgrade attacks that decrypt supposedly encrypted traffic.

User input inserted into LDAP search filters without escaping, allowing attackers to manipulate directory queries, bypass authentication, or extract sensitive directory data.

XML parsers configured to process external entity references, allowing attackers to read arbitrary files from the server or trigger SSRF by crafting a malicious XML payload.

User-controlled input included in HTTP response headers without sanitization, allowing attackers to inject arbitrary headers or split the response into two separate HTTP responses.

Unsanitized user input used in email To, From, CC, or Subject fields, allowing attackers to inject additional recipients and turn your email server into a spam relay.

User-supplied input written to logs without sanitization, allowing attackers to forge log entries, hide their tracks, or inject malicious content into log files.

User input passed directly into a template engine's render function, allowing attackers to execute arbitrary code on the server by injecting template syntax.

The server reuses the same session ID before and after login, allowing an attacker who planted a known session ID to hijack the authenticated session.

Login endpoints with no rate limiting or lockout mechanism, allowing attackers to try unlimited username and password combinations until they find valid credentials.

No minimum length, complexity, or common-password requirements on registration or password change, making user accounts easily brute-forced or guessed.

OAuth authorization flow implemented without a random `state` parameter, allowing CSRF attacks that link a victim's account to the attacker's OAuth identity.

JWT or session tokens remain valid after a user logs out because there is no server-side revocation mechanism, allowing stolen tokens to be used indefinitely.

Active sessions remain valid after a user changes their password, leaving attackers who already compromised a session with continued access even after the user takes remediation action.

Persistent 'remember me' tokens that are predictable, non-expiring, or stored insecurely — allowing attackers to forge tokens or maintain access indefinitely after compromise.

Password reset tokens without expiration, single-use enforcement, or proper randomness — allowing attackers to use leaked or guessable reset links to take over accounts.

Login or password reset endpoints returning different error messages for 'email not found' vs 'wrong password', allowing attackers to confirm which email addresses are registered.

Malicious scripts executed by reading attacker-controlled data from the URL or browser APIs and writing it to the DOM using dangerous sinks like innerHTML or document.write.

User-supplied content saved to the database without sanitization and rendered in the browser as HTML, allowing persistent script injection that executes for every user who views the content.

window.addEventListener('message') handlers that process messages without checking the event.origin, allowing any website to send commands to your app's message handler.

Absence of both X-Frame-Options and CSP frame-ancestors headers, combined with no client-side frame-busting logic, leaving the app fully embeddable in malicious iframes.

Third-party or user-generated content loaded in an iframe without the sandbox attribute, allowing that content to run scripts, access parent cookies, and navigate the top-level frame.

CDN-hosted scripts and stylesheets loaded without the integrity attribute, meaning a compromised CDN can serve malicious versions of your dependencies to all your users.

JavaScript that redirects users to URLs taken from query parameters or URL fragments without validation, enabling phishing attacks using your trusted domain as a launchpad.

Tokens, passwords, or sensitive identifiers passed as URL query parameters, where they're visible in browser history, server logs, Referrer headers, and shared links.

Swagger UI, ReDoc, or other API documentation interfaces publicly accessible in production, giving attackers a free interactive map of every endpoint, parameter, and authentication method.

GraphQL introspection is left enabled in production, allowing anyone to query the complete schema and discover all types, fields, mutations, and their argument structures.

GraphQL API with no depth limit on nested queries, allowing attackers to craft deeply nested queries that exhaust server resources and cause denial of service.

GraphQL endpoints accepting arrays of operations without size limits, enabling attackers to bypass rate limiting by bundling thousands of requests into a single HTTP call.

API endpoints returning full database objects with sensitive fields instead of only the fields the client actually needs, exposing password hashes, internal IDs, admin flags, and other sensitive data.

API endpoints that return all matching records without pagination or limit, enabling attackers to dump entire tables and causing memory/performance issues under normal load.

Using admin or full-access API keys for operations that only require read access, meaning a compromised key gives attackers far more access than needed for the intended operation.

Database connection URLs containing usernames and passwords are hardcoded in source code, making credentials accessible to anyone with repo access.

Database dump files (.sql, .dump, .bak) committed to the repository expose the entire database schema and data, including user credentials and sensitive records.

Using raw SQL methods like Prisma's $queryRaw or Sequelize's query() with string interpolation bypasses the ORM's built-in SQL injection protection.

Deserializing untrusted data with libraries like node-serialize or Python's yaml.load allows attackers to execute arbitrary code on the server.

Unbounded relation expansion in ORM queries allows attackers to trigger thousands of database queries with a single API request, causing denial of service.

File paths constructed with unvalidated user input allow attackers to read or write arbitrary files on the server using ../ sequences.

Accepting file uploads without verifying type, size, or content allows attackers to upload malicious executables, web shells, or oversized files that crash the server.

Accepting SVG uploads without sanitization allows attackers to embed JavaScript in SVG files, enabling XSS attacks when the SVG is rendered in a browser.

Images served without stripping EXIF metadata can leak GPS coordinates, device information, timestamps, and other sensitive data about the person who took the photo.

Injecting HTML or JavaScript into PDF generation templates allows attackers to read server-side files, make internal network requests, or execute scripts in the PDF viewer.

Extracting ZIP archives without validating file paths allows attackers to craft archives that write files outside the target directory, overwriting critical application files.

Validating file type only by extension instead of content allows attackers to upload malicious files with renamed extensions, bypassing security controls.

Read-modify-write payment operations without database transactions allow attackers to exploit timing windows and spend the same balance multiple times.

Accepting prices from the client instead of looking them up server-side allows attackers to modify checkout requests and purchase items at any price they choose.

Feature flags included in the frontend JavaScript bundle reveal unreleased features, internal testing configurations, and potential attack surfaces to anyone inspecting the code.

Development and testing routes like /debug, /test, /seed, or /api/dev left active in production expose internal data, bypass authentication, or allow state manipulation.

Profile update endpoints that accept role or permission fields from the request body allow users to promote themselves to admin by adding role: 'admin' to their update request.

Using standard string comparison (=== or ==) for secrets like API keys or tokens allows attackers to guess values character by character by measuring response time differences.

Redirecting users to URLs from unvalidated query parameters allows attackers to craft phishing links that appear to come from your trusted domain.

Passing the entire request body directly to database create or update operations allows attackers to set any field, including internal ones like verified, credits, or billing status.

Using ECB (Electronic Codebook) mode for encryption produces identical ciphertext blocks for identical plaintext blocks, revealing patterns in the encrypted data.

Using a hardcoded or constant Initialization Vector (IV) or nonce for encryption defeats the purpose of the IV and allows attackers to detect patterns and decrypt data.

Using cryptographic keys shorter than recommended minimums (RSA less than 2048 bits, AES less than 128 bits) makes encryption vulnerable to brute-force attacks with modern hardware.

Disabling TLS certificate validation with NODE_TLS_REJECT_UNAUTHORIZED=0 or rejectUnauthorized: false allows man-in-the-middle attacks on all HTTPS connections.

Using Math.random() or Date.now() to generate tokens, session IDs, or reset codes produces predictable values that attackers can guess or reproduce.

Accepting 'none' as a valid JWT signing algorithm lets attackers forge tokens without a secret key.

Embedding encryption keys as string literals in code means anyone with repo access can decrypt your data.

Merging user-controlled objects without filtering lets attackers modify Object.prototype and affect every object in the application.

Regular expressions with nested quantifiers can take exponential time to evaluate certain inputs, freezing your Node.js event loop.

Using Math.random() for security-sensitive values like tokens or IDs is predictable and can be brute-forced.

A service worker registered without scope restrictions can intercept all network requests for a domain, including those from other pages.

Serverless functions without a configured timeout can be kept running indefinitely by malicious or malformed requests, draining your budget.

Giving serverless functions or services more IAM permissions than they need turns a minor breach into a full account compromise.

Logging process.env dumps all your secrets — API keys, database passwords, signing keys — directly into your log system.

Serverless functions reuse execution environments between invocations, so sensitive files written to /tmp can be read by later requests from different users.

Global variables in serverless functions persist across invocations in the same execution environment, leaking user data between requests.

Installing a package with a name one character off from a popular library can install malware instead of the real package.

Dependencies that haven't been updated in 2+ years are unlikely to receive security patches when new vulnerabilities are discovered.

npm postinstall scripts run automatically with your system permissions during npm install, making them a common vector for malware.

Private internal packages without a scope prefix can be hijacked by publishing a higher-versioned public package with the same name.

Without a lockfile, npm install resolves the latest compatible version of every dependency — which can introduce a newly compromised package on your next deploy.

Custom URL schemes without host verification let malicious apps intercept your app's deep links and steal OAuth tokens or sensitive parameters.

Sensitive data copied to the clipboard (passwords, tokens, card numbers) persists there indefinitely and can be read by any app.

Banking and payment screens without screenshot protection allow sensitive data to be captured by malware or appear in Android's recent apps screen.

Without certificate pinning, attackers on the same network can intercept your app's HTTPS traffic with a rogue certificate authority.

Running a financial or health app on a rooted or jailbroken device means all security controls can be bypassed by the device owner.

Biometric authentication that only runs client-side can be bypassed by patching the app binary — the server must validate the session independently.

Containers that run as root give any code execution vulnerability immediate root access to the container — and potentially the host.

Using FROM image:latest means a new pull can silently change your base image, breaking reproducibility and potentially introducing vulnerabilities.

Secrets added via ENV, ARG, or COPY .env in a Dockerfile are baked into the image layers and readable by anyone who pulls the image.

EXPOSE-ing ports your application doesn't actually use increases the attack surface without any benefit.

Without a HEALTHCHECK instruction, Docker and orchestrators can't detect when your container is running but broken — routing traffic to a dead app.

Without SPF, DKIM, and DMARC DNS records, anyone can send emails claiming to be from your domain — enabling phishing attacks against your users.

Including unvalidated user input in SMS messages allows attackers to inject newlines and craft fraudulent messages appearing to come from your application.

Including unsanitized user input in push notification payloads allows attackers to craft misleading notifications in your app's name.

Accepting any password — including '123' or 'a' — makes your user accounts trivially vulnerable to credential stuffing and brute force attacks.

A login endpoint without rate limiting can be brute-forced thousands of times per second until a valid password is found.

Without multi-factor authentication, a stolen or guessed password is all it takes to fully compromise an account.

Allowing unverified email accounts lets attackers register with someone else's email address, potentially locking them out or impersonating them.

Password reset links that never expire stay valid indefinitely — an old email in a breach gives attackers a permanent account takeover path.

Not providing a 'log out all devices' option leaves sessions active on stolen or forgotten devices indefinitely.

Not notifying users of new logins means they have no way to know if their account was accessed from an unfamiliar device.

Without real-time feedback on password strength, users default to weak passwords they already know — even when you require complexity.

Destructive or irreversible actions (delete account, transfer funds, change email) without a confirmation step are vulnerable to CSRF and accidental clicks.

Without a .env.example file, new contributors don't know what environment variables are required, leading to insecure workarounds like hardcoding values.

Without security-focused ESLint rules, common vulnerabilities like XSS sinks, dangerouslySetInnerHTML, and eval() usage slip through code review.

Without pre-commit hooks that scan for secrets and security issues, developers can accidentally push API keys and passwords to the repository.

A .gitignore that doesn't cover .env files, build artifacts, and IDE configs can lead to secrets or sensitive data being accidentally committed.

npm scripts that fetch and execute remote code, or that embed secrets as shell arguments, are a supply chain and credential exposure risk.

A project without a committed lockfile can install different dependency versions on each machine, making builds non-reproducible and supply chain attacks harder to detect.

Test files with hardcoded real email addresses, phone numbers, or production-like credentials can leak PII and create security confusion.

Logging passwords, tokens, full user objects, or payment data to the console sends that data to your log aggregator in plaintext.

Returning stack traces or internal error details in API responses reveals your file structure, library versions, and code paths to attackers.

Without error boundaries, a JavaScript error in any component crashes the entire React tree and shows a blank screen to the user.

Not logging security events (failed logins, permission denials, suspicious actions) means you can't detect attacks in progress or reconstruct what happened after a breach.

Logging personally identifiable information (email, full name, IP address, phone number) creates privacy and compliance risks under GDPR and CCPA.

Running Node.js without NODE_ENV=production enables verbose error messages, disables caching optimizations, and can activate development-only middleware.

Debug mode enabled in production exposes internal state, enables verbose logging, and sometimes activates interactive debugging endpoints that attackers can exploit.

Without a /health endpoint, load balancers and orchestrators can't verify your application is actually working before routing traffic to it.

Without error monitoring, production errors are invisible until a user reports them — which most never do.

Using development credentials (test API keys, local database URLs, sandbox payment keys) in production puts real users at risk.

Without regular tested backups, a ransomware attack, accidental deletion, or database corruption can result in permanent data loss.

Sessions that never expire stay valid indefinitely, giving attackers unlimited time to use stolen tokens.

Operating without a privacy policy violates GDPR, CCPA, and similar regulations — and makes users rightfully distrust your handling of their data.

Without terms of service, you have no legal basis to restrict abuse, terminate accounts, or limit your liability for user-generated content.

Not offering account deletion violates GDPR's right to erasure and CCPA's right to delete — and is a significant privacy red flag for users.

Setting non-essential cookies without user consent violates GDPR and ePrivacy Directive requirements for EU users.

Storing full card numbers, CVVs, or PANs in localStorage, sessionStorage, or your own database violates PCI DSS and creates massive liability.

Running user tracking, fingerprinting, or behavioral analytics without explicit consent violates GDPR, CCPA, and similar privacy laws.

Collecting more personal data than you need violates GDPR's data minimization principle and increases your liability when a breach occurs.

Not showing users their account's last activity makes it harder for them to detect unauthorized access.

Sending passwords, full tokens, card details, or excessive personal data in emails exposes that data to email providers, forwarding recipients, and anyone with inbox access.

Email and SMS endpoints without rate limiting can be abused to spam users or drain your sending budget through automated requests.

Push notification payloads are visible on the lock screen and logged by notification services — don't include account numbers, balances, or personal identifiers.

File upload endpoints without size limits allow attackers to exhaust disk space, memory, and CPU with multi-gigabyte uploads.

JSON API endpoints without a body size limit can be DoS'd by sending huge JSON payloads that exhaust server memory during parsing.

Without global rate limiting at the edge or middleware level, any endpoint can be flooded with requests until the server is overwhelmed.

HTTP requests without server-side timeouts allow slow clients or malicious slow-body attacks to hold server connections open indefinitely.

WebSocket endpoints that accept connections without verifying authentication allow unauthenticated users to receive real-time data streams meant for authenticated users.

User input is concatenated directly into an LLM prompt, letting attackers override your instructions and make the AI do things you never intended.

Your app sends personally identifiable information — emails, names, passwords, phone numbers — to external AI APIs, exposing user data to third-party model providers.

LLM output is rendered or executed directly without checking whether it matches the expected format or contains harmful content.

Your OpenAI, Anthropic, or other AI API key is exposed in client-side code, where anyone can steal it and rack up charges on your account.

LLM-generated HTML or code is rendered directly in the UI without sanitization, opening the door to stored XSS attacks.

Your app sends entire database records, config files, or secrets as context to an AI model, exposing far more data than the task requires.

When the primary AI model fails, your app silently falls back to a weaker or unvalidated model that bypasses your safety configurations.

Your app makes AI API calls with no per-user limits, letting a single user (or bot) trigger thousands of requests and drain your API budget in minutes.

Your app uses eval() or Function() to execute code that was generated by an LLM, giving attackers a path to arbitrary code execution via prompt injection.

Your database connection doesn't use SSL/TLS, meaning all queries and results travel over the network in plaintext and can be intercepted.

Your database is bound to 0.0.0.0 or exposed on a public IP without a VPC or firewall, making it directly reachable from the internet.

Your database uses factory-default credentials like postgres:postgres, root:root, or admin:admin — the first thing any attacker tries.

A database connection string with a plaintext password is hardcoded in your source code, committing your database credentials to version control.

Your MongoDB connection has no authentication credentials, allowing anyone who can reach the database port to read, modify, or delete all data.

Your Redis instance has no password and is accessible beyond localhost, letting anyone who can reach it read all cached data, session tokens, and queue contents.

Your Elasticsearch instance is reachable from the internet without authentication, exposing all indexed data to anyone who knows the endpoint URL.

Your database connection pool has no max connection limit, meaning a traffic spike or slow query can exhaust all available database connections and take your app down.

Your database connection has no timeout configured, so a slow or unresponsive database will hang your entire application indefinitely instead of failing fast.

Your DATABASE_URL or database password gets printed to application logs via console.log or error messages, exposing credentials to anyone with log access.

Your database SSL connection uses rejectUnauthorized: false, which encrypts traffic but doesn't verify the server's identity, leaving you open to man-in-the-middle attacks.

Your database hostname and port are hardcoded in source code instead of environment variables, exposing your infrastructure topology and making deployments inflexible.

Your S3 bucket is publicly readable due to a public ACL, disabled Block Public Access settings, or a wildcard bucket policy — anyone on the internet can list and download your files.

Your app fetches user-supplied URLs without blocking cloud metadata endpoints like 169.254.169.254, letting attackers steal your cloud credentials via SSRF.

AWS access keys (starting with AKIA) or secret access keys are hardcoded in your source code, giving anyone who reads the code full access to your AWS account.

Your IAM policy uses Action: '*' or Resource: '*', granting far more permissions than needed and turning any credential leak into a full account takeover.

Your S3 or GCS bucket has CORS configured with origin: '*' or AllowedMethods: ['*'], letting any website read your storage responses and potentially access private data.

Your Lambda or Cloud Function allows unauthenticated invocation, meaning anyone on the internet can trigger it without credentials.

Your S3 or GCS bucket doesn't have server-side encryption enabled, meaning data is stored in plaintext on AWS/Google's infrastructure.

Your KMS encryption keys don't have automatic rotation enabled, meaning the same key material is used indefinitely — increasing the risk if the key is ever compromised.

Your IAM trust policy uses a wildcard principal or allows unknown AWS accounts to assume your roles, letting external accounts access your resources.

Your app logs PII, tokens, or credentials to CloudWatch, Stackdriver, or other cloud logging services, where they persist indefinitely and are accessible to anyone with log read permissions.

Your cloud resources are deployed without a VPC or with security groups that allow unrestricted inbound traffic (0.0.0.0/0), exposing internal services to the internet.

Your cloud resources lack environment, owner, or cost-center tags, making it impossible to track ownership, allocate costs, or quickly identify resources during an incident.

Your terraform.tfstate file is committed to your repository or stored in an unencrypted, publicly accessible location — it contains every secret and resource ID in your infrastructure.

AWS, GCP, or Azure credentials are hardcoded in your .tf files instead of using environment variables or instance roles, committing cloud access keys to version control.

Your Kubernetes pod runs with securityContext.privileged: true, giving the container full access to the host kernel and effectively bypassing container isolation.

Pods running with the default service account inherit cluster-level RBAC permissions that are often far more powerful than the workload needs, enabling lateral movement if the pod is compromised.

Passwords, API keys, and other secrets are hardcoded directly in Helm values.yaml files, which get committed to version control and exposed to anyone with repository access.

Without NetworkPolicy resources, every pod in the cluster can communicate with every other pod on any port, enabling unrestricted lateral movement after a single pod is compromised.

Kubernetes Secrets are stored as base64-encoded plaintext in etcd by default, meaning anyone with access to the etcd datastore or its backups can read every secret in the cluster.

Without running terraform plan in CI or a drift detection tool, manual changes to cloud resources go undetected, creating security gaps between your declared infrastructure and what actually runs in production.

Using GitHub Actions referenced by mutable tags like @main or @v3 instead of full commit SHAs means a compromised or hijacked action can inject malicious code into your CI pipeline without any change to your workflow file.

Using untrusted event data like github.event.issue.title directly inside run: blocks allows attackers to inject arbitrary shell commands into your CI pipeline by crafting malicious issue titles, PR bodies, or commit messages.

Printing or echoing environment variables containing secrets in CI scripts exposes them in build logs, which are often accessible to all repository collaborators and sometimes publicly visible on open-source projects.

Using self-hosted GitHub Actions runners with pull_request_target or public fork workflows allows untrusted code from external contributors to execute on your infrastructure with access to secrets, persisted state, and the host network.

GitHub Actions workflows with permissions: write-all or no explicit permissions block grant the GITHUB_TOKEN excessive access, allowing a compromised step to modify code, create releases, write packages, or change repository settings.

Without branch protection on main/production branches, any developer (or compromised account) can push directly, force-push destructive changes, or merge without code review, bypassing all quality and security gates.

A CI/CD pipeline that only runs tests and linting without any SAST, DAST, dependency scanning, or secret detection means vulnerabilities are only found after deployment -- if they are found at all.

Build artifacts (binaries, container images, packages) produced without cryptographic signatures or provenance attestations can be silently replaced by an attacker between the CI build and deployment, resulting in supply chain compromise.

A WebSocket server that does not check the Origin header accepts connections from any website, allowing cross-site WebSocket hijacking where a malicious page connects to your WS endpoint using the victim's authenticated session.

A WebSocket server without message rate limiting allows a single client to send thousands of messages per second, exhausting server resources, degrading performance for all users, and potentially causing a denial-of-service.