Every web application has a threat model, but few development teams work through it systematically. That gap is precisely why the OWASP Top 10 vulnerabilities list exists. Published by the Open Web Application Security Project, the list identifies the ten most critical security risks facing web applications today, ranked by prevalence, exploitability, and business impact.
If you are building a career in ethical hacking or penetration testing, this list is foundational, and if you want a broader framework for where OWASP fits, start with the complete ethical hacking and security testing guide before diving deeper.
Specifically, this article covers all ten categories from the 2025/2026 cycle — what each vulnerability is, how attackers exploit it, what it looks like in the wild, and how to defend against it. The goal is a practical reference you can use in code reviews, bug bounty work, or pentest engagements.
What Is the OWASP Top 10?
The Open Web Application Security Project (OWASP) is a nonprofit foundation that produces freely available tools, documentation, and standards to improve software security. OWASP updates its flagship publication, the OWASP Top 10, approximately every three to four years. The organization bases each update on data collected from contributing organizations, security firms, and bug bounty programs. The current cycle draws on more than 12 million real-world security incidents.
The list is not a compliance checklist. Instead, it is a risk register — a prioritised view of where attackers are most successfully compromising web applications right now. Developers use it to identify dangerous design patterns early. Similarly, pentesters use it as a coverage checklist, and bug bounty hunters treat it as a targeting framework.
OWASP assigns each category an identifier (A01 through A10) and provides a description of the flaw, common attack patterns, example incidents, and recommended mitigations.
OWASP Top 10 Vulnerabilities, 2025/2026 List
The table below provides a quick reference across all ten categories. Detailed breakdowns for each follow in the sections ahead.
| ID | Vulnerability | Risk Level | Primary Attack Vector |
| A01 | Broken Access Control | Critical | IDOR, privilege escalation, forced browsing |
| A02 | Cryptographic Failures | High | Weak encryption, plaintext storage, outdated algorithms |
| A03 | Injection | High | SQL, command, XSS, LDAP injection |
| A04 | Insecure Design | High | Architectural flaws, missing threat modelling |
| A05 | Security Misconfiguration | High | Default creds, debug mode, exposed cloud buckets |
| A06 | Vulnerable & Outdated Components | Medium–High | Unpatched libraries, supply chain exploitation |
| A07 | ID & Authentication Failures | High | Credential stuffing, weak sessions, MFA bypass |
| A08 | Software & Data Integrity Failures | High | Supply chain attacks, CI/CD poisoning |
| A09 | Security Logging & Monitoring Failures | Medium | No alerting, long attacker dwell time |
| A10 | Server-Side Request Forgery (SSRF) | High | Cloud metadata access, internal network pivoting |
A01, Broken Access Control
Broken access control is the most common finding in web application security assessments, which is exactly why it sits at the top of the list. This vulnerability occurs when an application fails to properly enforce what authenticated or unauthenticated users can access or perform.
How Attackers Exploit It
The most frequent technique is Insecure Direct Object Reference (IDOR): a user changes a numeric ID in a URL or API request and gains access to another user’s data. Beyond IDOR, more sophisticated variants include vertical privilege escalation, a standard user manipulating a cookie or role parameter to gain admin access, and forced browsing, where simply knowing an endpoint URL is enough to access restricted functionality.
Developers also introduce risk through patterns such as missing function-level access controls on API endpoints (for example, failing to verify permissions on DELETE or administrative routes) and HTTP method tampering, where attackers send unexpected request methods to bypass application logic.
Real-World Examples
Facebook’s IDOR vulnerabilities exposed user data in private albums. Instagram users could access other accounts by manipulating mobile API requests. GitHub researchers were able to access repositories belonging to other organisations. These were not sophisticated zero-day exploits. In each case, they were access control checks that were either missing or inconsistently applied.
Detection and Prevention
Enforce role-based access checks server-side on every request, because attackers can bypass client-side JavaScript checks trivially with tools such as Burp Suite or curl. Developers should avoid exposing sequential integer IDs and use UUIDs instead. They should also enforce a default-deny policy, granting access explicitly rather than assuming it by default. Audit regularly using tools like the Autorize Burp plugin to replay requests with different privilege levels.
Quick Recap:Broken access control is the #1 OWASP risk. IDOR, privilege escalation, and forced browsing are the primary attack patterns. Every API endpoint needs a server-side permission check.
A02, Cryptographic Failures
Cryptographic failures cover a wide range of weaknesses: data transmitted without TLS, passwords stored as plaintext or with broken hashes like MD5 or SHA-1, sensitive data left in logs, and encryption keys hardcoded in source repositories. The unifying thread is a failure to protect data, whether at rest or in transit.
What This Looks Like in Practice
An application storing passwords with MD5 means a single database breach hands attackers cracked credentials immediately. An HTTP-only login page exposes session tokens to any attacker on the same network segment. Automated scanners can harvest an API key from a public GitHub repository within minutes. Recent Google API key exposure incidents demonstrate how quickly attackers can abuse exposed credentials.
Outdated algorithms create significant risk because they still appear secure at first glance. MD5 and SHA-1 continue to generate hashes, but attackers can crack those hashes using commodity hardware and precomputed rainbow tables.
Prevention
Use AES-256 for data at rest and TLS 1.2+ (ideally TLS 1.3) for data in transit. Hash passwords with bcrypt, scrypt, or Argon2, never MD5, SHA-1, or unsalted SHA-256. Store encryption keys in a secrets manager (AWS Secrets Manager, HashiCorp Vault) rather than in source code or environment files. Additionally, never log sensitive values like tokens or passwords, even in debug mode.
A03, Injection
Injection vulnerabilities occur when an application passes untrusted user input directly to an interpreter, a database, the operating system shell, an LDAP server, or even an AI model prompt, without proper sanitisation or parameterisation. The attacker’s input is treated as a command rather than data.
SQL Injection
SQL injection remains the canonical example. A login form that constructs a query via string concatenation can be bypassed with a payload like ‘ OR ‘1’=’1. More advanced variants, blind SQL injection and time-based blind injection, do not require visible output, instead using conditional delays or boolean logic to extract data bit by bit.
Tools like SQLMap automate the entire process of detection and exploitation. Therefore, understanding how they work is essential for anyone serious about web application penetration testing, knowing how SQLMap operates helps you both test applications and understand what defenses actually stop it.
Command Injection and XSS
Command injection happens when user input reaches an OS shell call, for example, a ping-an-IP feature that passes user input directly to a system command. A semicolon appended to the input allows the attacker to chain arbitrary system commands, potentially escalating to a full reverse shell.
Similarly, cross-site scripting (XSS) is the browser-side variant: malicious JavaScript injected into a page runs in the browser of anyone who visits it. Stored XSS (persisted to a database and served to all users) is the most severe form, enabling session hijacking, credential harvesting, and even worm propagation, the 2009 Twitter self-retweeting worm used stored XSS in profile bios.
Prevention
Use parameterised queries or prepared statements, never build SQL from string concatenation. For OS commands, avoid them entirely where possible; if unavoidable, escape arguments with the language’s built-in safe functions (e.g., PHP’s escapeshellarg()). For XSS, encode output at render time based on context (HTML, JS, CSS, URL), use Content Security Policy headers, and set cookies as HttpOnly.
Quick Recap:Injection attacks (SQL, command, XSS) all share the same root cause: trusting user input. Parameterised queries, output encoding, and input validation eliminate the majority of injection risk.
A04, Insecure Design
Insecure design marks a major shift in the OWASP Top 10 because it focuses on architectural mistakes rather than specific coding flaws. Teams often introduce these weaknesses before developers write a single line of code. This distinction matters because developers can patch a code-level bug, but architectural flaws often require substantial redesign. An insecure design may require rearchitecting the entire feature.
Common Patterns
A shopping cart that trusts the price value submitted from the client browser is an insecure design, not a code bug. A password reset flow that relies on knowing a user’s pet’s name or mother’s maiden name is insecure by design. As a result, an application that doesn’t model threats during the design phase will inevitably ship with classes of vulnerability that no amount of code-level patching will fully address.
The fix is threat modelling: asking, at design time, how could this feature be abused? What happens if a malicious actor controls this input? What is the worst-case failure mode of this component?
Prevention
Integrate threat modelling into the design phase using frameworks like STRIDE or the PASTA methodology. In addition, use secure design patterns and never trust client-supplied values for pricing, permissions, or identity. Most importantly, engage security engineers in architecture reviews before development starts, not after the first pentest finds a fundamental flaw.
A05, Security Misconfiguration
Security misconfiguration is broad: default credentials left unchanged, debug mode enabled in production, directory listing enabled on a web server, an S3 bucket set to public, overly permissive CORS policies, verbose error messages leaking stack traces. One-third of all security breaches trace back to a misconfiguration, and almost all of them are preventable.
How Attackers Find It
Automated scanners probe for misconfigurations at scale. A Shodan query for default Tomcat credentials, an exposed Kubernetes dashboard, or an accessible AWS metadata endpoint will surface thousands of targets in seconds. In practice, attackers don’t need to be clever, they need to be systematic, and automation does the work for them.
Real-World Incidents
The 2017 Equifax breach involved a misconfigured Apache Struts server that had not been updated after a known vulnerability was published. Likewise, Uber and Accenture both suffered data leaks from cloud storage buckets left publicly accessible. Even internal tools, Redis instances exposed to the internet with no authentication, have become routine targets for ransomware operators.
Prevention
Run hardening scripts against all servers before deployment. Change all default passwords and secret keys. Disable debug mode, directory listing, and unused services. Use infrastructure-as-code tools to enforce configuration baselines and catch drift. Run automated misconfiguration scanners like Scout Suite, Lynis, or OWASP ZAP as part of CI/CD pipelines.
A06, Vulnerable and Outdated Components
Modern applications are assembled from third-party libraries, frameworks, and runtime environments. A typical npm audit on a mid-sized project surfaces over a thousand vulnerabilities, not because the application code is bad, but because each dependency brings its own risk surface. If an attacker can find a critical CVE in a library version pinned in your package.json, your application inherits that vulnerability regardless of how well your own code is written.
The Dependency Problem
However, developers frequently pin dependency versions for reproducibility and then forget to update them. Organizations frequently ignore security patches for popular libraries such as Log4j (Log4Shell), Apache Struts, and OpenSSL for months after vendors release them. The Equifax breach, one of the largest in history, occurred because the company failed to apply an Apache Struts patch that had been available for two months before attackers exploited the vulnerability.
Prevention
Generate and maintain a Software Bill of Materials (SBOM) for every application — a complete inventory of every component and its version. Furthermore, use dependency scanning tools (Snyk, Dependabot, OWASP Dependency-Check) and configure automated alerts for new CVEs affecting your dependencies. Pin and verify checksums for critical packages to detect supply chain tampering.
Quick Recap:Broken access control, injection, cryptographic failures, and security misconfiguration are the four most commonly exploited OWASP categories. Most can be addressed with server-side validation, updated dependencies, and configuration management.
A07, Identification and Authentication Failures
Authentication failures cover weaknesses in the mechanisms used to verify user identity: weak password policies, missing account lockout allowing brute force, insecure session management, and flawed multi-factor authentication implementations. Once authentication is broken, every other security control becomes irrelevant.
Credential Stuffing and Brute Force
Credential stuffing uses username-password pairs leaked in previous breaches, exploiting the reality that a large percentage of users reuse passwords across sites. As a result, tools automate this at scale — one leaked database becomes access to accounts on dozens of other platforms. Brute force attacks are cruder but effective against applications with no rate limiting or account lockout, tools like Hydra and Burp Suite Intruder make them trivially easy to run.
Session Hijacking
Even so, secure authentication at login means nothing if the session token issued afterward is predictable, transmitted over HTTP, or stored without the Secure and HttpOnly flags. An attacker who captures a valid session cookie, via packet sniffing on an unencrypted connection, via XSS, or via a leaked log file, can authenticate as that user without ever knowing the password.
A 2021 attack that bypassed two-factor authentication via a simple API design flaw resulted in $2.1 million stolen in three hours, highlighting that MFA can be defeated if the implementation has gaps.
Prevention
Enforce strong password policies with minimum length and complexity requirements. Implement rate limiting and account lockout after repeated failed attempts. Use secure, random session IDs and invalidate them on logout and after inactivity. Deploy phishing-resistant MFA, FIDO2/WebAuthn is significantly harder to bypass than SMS or TOTP codes. Never transmit session tokens over HTTP.
A08, Software and Data Integrity Failures
This category addresses supply chain attacks and the trust we place in software updates, external libraries, and data pipelines without verifying their integrity. If an attacker can compromise a trusted update mechanism or a widely-used open-source package, they get code execution on every system that installs the compromised version.
Supply Chain Attacks
The SolarWinds Orion attack is the defining case: attackers compromised the build system and shipped a Trojanized update to thousands of customers, including US government agencies. The malware was signed with the legitimate SolarWinds certificate, meaning endpoint security tools saw it as trusted software. In the same way, the event-stream npm package incident showed this pattern on a smaller scale: a malicious contributor added cryptocurrency wallet-stealing code to a JavaScript library downloaded millions of times per week.
CI/CD Pipeline Risks
Furthermore, if an attacker gains write access to a CI/CD pipeline, they can inject malicious code that gets compiled, signed, and shipped as part of a legitimate software release. Weak access controls on build systems, shared secrets, overprivileged service accounts, no MFA on pipeline administrator accounts, are routinely exploited in red team engagements.
Prevention
Verify digital signatures on all software updates before applying them. Add subresource integrity (SRI) hashes to externally loaded scripts. Use the SLSA (Supply Chain Levels for Software Artifacts) framework to enforce build provenance. Harden CI/CD pipelines with MFA, least-privilege service accounts, and pipeline-as-code that is itself version-controlled and audited.
A09, Security Logging and Monitoring Failures
Security logging and monitoring failures are different in character from the other nine categories. They do not directly enable an attack, they enable attackers to persist undetected. The average dwell time between initial compromise and discovery is over 200 days. Without adequate logging and alerting, most organisations simply cannot detect that they have been breached until it is too late to minimise the damage.
What Good Logging Looks Like
Effective security logging captures failed login attempts, successful logins from unusual locations, privilege escalations, file access on sensitive paths, configuration changes, and errors that indicate exploitation attempts. Logs should be centralised, a SIEM like Splunk, Graylog, or the ELK stack, so that cross-system correlation is possible.
Real-World Cost of Monitoring Gaps
Target’s 2013 breach cost over $200 million. Although the security tools generated alerts during the attack, nobody acted on them. Equifax’s 2017 breach went undetected for 76 days because logs existed but were not being correlated. Similarly, the Capital One breach in 2019 was discovered only because the attacker bragged about it online — the organisation’s own monitoring systems did not catch it.
Prevention
Log the right events, not everything, but specifically failed authentication, access to sensitive endpoints, and anomalous traffic patterns. Equally important, centralise logs to a tamper-resistant system separate from the application servers. Automate alerting: five failed logins from the same IP in two minutes should trigger an alert, not sit silently in a log file. Test monitoring with red team exercises that simulate real attack patterns.
A10, Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) occurs when a web application fetches a resource from a URL provided by the user, and does so without validating that the destination is safe. The attacker’s goal is not to hit an external target, it is to make the application’s own server act as a proxy, reaching internal systems that are not directly accessible from the internet.
Why SSRF Is Dangerous
Cloud-hosted applications are particularly vulnerable. AWS, Google Cloud, and Azure all expose instance metadata services on internal IP addresses (169.254.169.254 in AWS). If an attacker can craft an SSRF payload that causes the application server to fetch this endpoint, they retrieve temporary IAM credentials. With those credentials, they can therefore access storage buckets, launch compute instances, and escalate privileges across the cloud account.
The Capital One breach followed exactly this pattern: an SSRF vulnerability in a web application firewall allowed the attacker to query the AWS metadata endpoint, retrieve temporary credentials, and then access 100 million credit card applications stored in S3 buckets. The total damages exceeded $150 million.
Attack Chain
A typical SSRF escalation path: find a URL-fetching feature (image preview, PDF generation, webhook configuration) → probe internal IP ranges (127.0.0.1, 10.0.0.0/8, 169.254.169.254) → access cloud metadata to harvest credentials → use credentials to pivot into databases, internal APIs, or cloud-managed services → establish persistence.
Prevention
The most effective defense is a strict allowlist: define exactly which external domains or IP ranges the application is permitted to fetch, and reject everything else. That said, blocking private IP ranges is a useful secondary control but is easier to bypass via DNS rebinding than an allowlist. Disable HTTP redirects in outbound fetch libraries where possible, and require resolved IP validation after DNS lookup. Monitor all outbound requests from application servers for anomalous destinations.
For a deeper look at how SSRF is tested in real engagements alongside other web vulnerabilities, see the full web application penetration testing methodology guide which covers reconnaissance through exploitation in detail.
Quick Recap:SSRF lets attackers use your server as a proxy into internal networks. Cloud metadata endpoints are the primary target. Allowlists, not blocklists, are the correct defense. SSRF is responsible for some of the largest cloud-infrastructure breaches on record.
How to Test for OWASP Top 10 Vulnerabilities
Understanding the theory is one thing; knowing which tools to use and what to look for is what separates conceptual knowledge from practical skill. The following maps each category to its primary testing approach.
| Category | Testing Tool(s) | Key Technique |
| A01 Broken Access Control | Burp Suite (Autorize plugin), Postman | Replay requests with different user tokens; manipulate object IDs |
| A02 Cryptographic Failures | Wireshark, SSL Labs, git-secrets | Sniff traffic; test TLS version; scan repos for hardcoded keys |
| A03 Injection | SQLMap, Burp Intruder, OWASP ZAP, XSStrike | Fuzz input fields; test parameterised vs raw query behaviour |
| A04 Insecure Design | Manual review, Threat Dragon | Architecture review; trust boundary analysis; abuse case scenarios |
| A05 Security Misconfiguration | OWASP ZAP, Nikto, Lynis, Scout Suite | Scan for default creds, open ports, debug endpoints |
| A06 Outdated Components | OWASP Dependency-Check, Snyk, Dependabot | Scan package manifests for known CVEs |
| A07 Auth Failures | Hydra, Burp Suite Intruder, jwt_tool | Brute force; session token analysis; MFA bypass testing |
| A08 Software Integrity | Hash verification, Sigstore, SLSA checks | Verify update signatures; audit CI/CD permissions |
| A09 Logging Failures | Manual testing, Splunk, ELK | Confirm alerts fire; check log retention; simulate attacks |
| A10 SSRF | Burp Suite, Collaborator, manual URL crafting | Probe internal IP ranges; test cloud metadata endpoints |
For hands-on practice with the tools listed above, the Burp Suite tutorial for web application testing covers the core workflow from proxy setup through active scanning and manual exploitation.
OWASP Top 10: How the List Has Evolved
OWASP updates the composition of the Top 10 with each revision to reflect changes in how developers build, deploy, and secure applications, as well as how attackers target them. The most significant trend across cycles from 2013 through the current 2025 list is the expansion of scope beyond traditional web application code into the entire software delivery and infrastructure ecosystem.
| Category | 2013 | 2017 | 2021 / 2025 |
| Access Control | Present | Present | A01, moved to #1 (was #5) |
| Injection | #1, top position | #1, held top position | A03, dropped from #1 as access control overtook it |
| Security Misconfiguration | Present | Present | A05, consistently present |
| SSRF | Absent | Absent | A10, new entry in 2021 cycle |
| Insecure Design | Absent | Absent | A04, new entry in 2021 cycle |
| Software Integrity | Absent | Partial (Insecure Deserialisation) | A08, broadened to cover CI/CD and supply chain |
| XML External Entities (XXE) | Absent | A4, standalone entry | Merged into Injection (A03) |
The addition of SSRF, Insecure Design, and Software & Data Integrity Failures as standalone categories reflects the realities of modern application architecture. Cloud-native deployments, third-party dependencies, and automated CI/CD pipelines have created attack surfaces that the 2013 version of the OWASP Top 10 was not designed to address.
OWASP Top 10 for Developers vs Pentesters
The same list serves two fundamentally different audiences, and the way each reads it differs.
Developer Perspective
Developers should read the OWASP Top 10 as a list of design and coding patterns to avoid. Parameterised queries prevent injection. Centralised access control logic prevents broken access control from propagating across hundreds of endpoints. TLS everywhere and bcrypt password hashing address cryptographic failures. The goal is to eliminate entire vulnerability classes through consistent engineering practices, not to patch individual instances.
Pentester and Bug Bounty Perspective
Security testers read the same list as a prioritised checklist for test coverage. Every OWASP category should be exercised on every target. For instance, access control testing with Autorize covers A01, injection fuzzing with SQLMap and Burp covers A03, and SSRF probing with internal IP payloads covers A10. A finding in any one of these categories is likely to be triaged quickly because the client’s security team will recognise it immediately.
Bug bounty programs often reward OWASP-category findings at the highest severity tiers. If you are just starting out, the bug bounty hunting guide for beginners covers how to approach scope selection and initial recon before you start testing for these vulnerabilities.
Value Insight: What OWASP Actually Tells You About Risk
OWASP builds the Top 10 using incident data rather than threat intelligence. This distinction is important because the list highlights vulnerabilities that attackers have already exploited successfully at scale, not vulnerabilities that are merely theoretical.
Consequently, the list has a meaningful lag. OWASP did not add SSRF as a formal category until 2021, even though security professionals had recognized it as a major attack class for years. The category only qualified after incident data met OWASP’s inclusion threshold. While AI prompt injection does not yet appear on the list, attackers actively exploit it in production systems today.
In practical terms, use the OWASP Top 10 as your baseline coverage, not your ceiling. For production applications with complex attack surfaces — particularly those using AI components, GraphQL APIs, or multi-cloud infrastructure — you should also supplement OWASP testing with the OWASP API Security Top 10, the OWASP AI Security Top 10, and your own threat model.
Treating OWASP as a compliance checkbox misses the point. The goal is to understand why each vulnerability class exists, how it manifests in your specific architecture, and what controls genuinely address the root cause rather than masking symptoms.
FAQ, OWASP Top 10 Vulnerabilities
How often is the OWASP Top 10 updated?
The list is typically revised every three to four years. The most recent major update reflects data from the 2021 cycle and remains the active reference for 2025/2026, with incremental guidance issued between formal releases.
Is OWASP Top 10 the same as a compliance requirement?
Not inherently, but several compliance frameworks reference it. PCI DSS requires testing for OWASP Top 10 vulnerabilities in web applications processing card data. Many enterprise security programmes and bug bounty platforms use it as a standard scope definition. It is best understood as an industry benchmark rather than a legal requirement.
Which OWASP Top 10 vulnerability is most commonly found in bug bounties?
Broken access control (A01) and injection (A03) are consistently the most reported categories in bug bounty programmes. IDOR vulnerabilities in particular are frequently found in APIs and mobile backends, often carrying medium to critical severity ratings.
What changed from OWASP 2017 to OWASP 2021/2025?
OWASP introduced several significant structural changes in the latest revision. The organization added SSRF as a standalone category, introduced Insecure Design as its own category, expanded Insecure Deserialization into Software & Data Integrity Failures to address broader supply chain and CI/CD risks, and merged XML External Entities (XXE) into Injection.
What tools cover OWASP Top 10 testing?
No single tool covers all ten categories comprehensively, but Burp Suite Professional is the closest to a universal platform, it addresses injection, access control testing, authentication analysis, and SSRF. Supplement with OWASP ZAP for passive and active scanning, SQLMap for SQL injection, and Snyk or OWASP Dependency-Check for vulnerable components.
Does OWASP Top 10 cover API security?
The standard OWASP Top 10 focuses on web applications. OWASP publishes a separate OWASP API Security Top 10 for APIs. This framework covers API-specific risks such as broken object-level authorization, excessive data exposure, and rate-limiting failures that the web application Top 10 does not fully address.
Conclusion
The OWASP Top 10 vulnerabilities are not a static set of bugs to patch and forget. Rather, they are a living taxonomy of the ways web applications fail, updated as the threat landscape evolves and underpinned by data from real breaches rather than theoretical risk models.
For developers, the list provides a prioritised set of engineering patterns to embed in every project from day one: parameterised queries, strict access control enforcement, correct cryptographic primitives, hardened configurations, and dependency management. For security testers and bug bounty hunters, it is the coverage checklist that ensures no major attack class is overlooked.
Building fluency with the OWASP Top 10 is one of the foundational steps on the path to becoming a professional ethical hacker. For a structured roadmap that covers the full skill progression, from lab setup through certifications, see the guide on how to become an ethical hacker.
Each category in this list represents a documented, proven attack vector. The defences exist, the tools exist, and therefore the gap between vulnerable and secure applications is almost always an engineering and process problem, not a knowledge problem.
Security & Legal Disclaimer:All techniques, tools, and examples discussed in this article are provided for educational and ethical security research purposes only. Testing for vulnerabilities must only be performed on systems you own or have explicit written authorisation to test. Unauthorised access to computer systems is illegal in most jurisdictions. Tigerzplace.com does not endorse or encourage any unlawful activity.