Built to be taken apart.

Insecurity is a family of deliberately vulnerable applications for penetration-testing practice. Each one is a complete working system rather than a set of exercises, and the family is ordered by attack surface — from a single bulletin board up to a federated enterprise.

The aim is range. The systems people are asked to assess are not all of one kind, and neither are these: the family spans the way applications were built years ago through to the way they are built now, because both are still deployed and they fail differently.

Start with Insecurity BBS The whole family

Why this exists

The work spans more than one kind of system

An assessment is rarely against the stack you would have chosen. An application written years ago and a service deployed last quarter are both in production somewhere, and the things that go wrong in them are not the same things. Practice that covers one end of that range prepares you for one end of the work.

What is available to practise on tends to take one of two shapes, and each is built for something other than this. Lesson-based applications introduce one named defect at a time, which teaches what a vulnerability is but not how to find one that nobody has labelled. Challenge tasks are puzzles with answers, reduced to the part that is interesting — which is the part a real target does not hand over. Both are useful. Neither is a system.

So the gap this fills is the middle: complete applications, built the way applications of their kind are actually built, where nothing is marked and deciding what is worth your attention is part of the exercise.

What this is

Complete systems, ordered by surface

Each product is a working application with a scope and an address, and nothing removed to make it a teaching aid.

Nothing is marked. No exercise list in the markup, no seeded credentials on the login page, no notes left in the source. The answer key sits beside the application rather than inside it, so reading it is a decision rather than an accident.
Built in the runtime it would really use. A product is implemented in the stack a deployment of it would actually run on, and where a product belongs to more than one, it is built for each. The same exercise ids carry across wherever the exercise itself survives the move.
The fix as well as the finding. Alongside each application are hardened counterparts of its most instructive files and a document that walks the diffs — what the fix is, and why it is that one rather than the filter that only resembles it.
Ordered by attack surface. The progression is the point. Each band models more than the one before it, so it can go wrong in ways the last one had no way to.

The whole family, banded by surface What Insecurity is

Before you clone anything

Read this part

Every application in this family is intentionally insecure. None of them belong on a network you share with anything else.

Run them on an isolated host only. The launchers refuse to bind anything but the loopback address unless you deliberately override it, and each repository carries a SECURITY.md that says what is exposed and how.