2 exploit the xkcd
source | link

When testing, it is very easy to test for what you expect to happen. For example, when filling in a "name" field in a database you will probably choose something you are familiar with, like "John Doe". This works, and your application seems to work fine.

Then, one day, someone names their child Robert'); DROP TABLE Students; -- (little Bobby Tables).

https://xkcd.com/327/enter image description here

Of course, you don't test your app for names like that, so the security hole that such a name exposes slips through all your testing.

There is an interesting comment here: The Unfalsifiability of Security Claims

It's easy to prove a security hole exists (you just test for a name like the above). It's also easy to prove that a particular hole has been fixed. It's hard to prove no other security holes exist.

When testing, it is very easy to test for what you expect to happen. For example, when filling in a "name" field in a database you will probably choose something you are familiar with, like "John Doe". This works, and your application seems to work fine.

Then, one day, someone names their child Robert'); DROP TABLE Students; -- (little Bobby Tables).

https://xkcd.com/327/

Of course, you don't test your app for names like that, so the security hole that such a name exposes slips through all your testing.

There is an interesting comment here: The Unfalsifiability of Security Claims

It's easy to prove a security hole exists (you just test for a name like the above). It's also easy to prove that a particular hole has been fixed. It's hard to prove no other security holes exist.

When testing, it is very easy to test for what you expect to happen. For example, when filling in a "name" field in a database you will probably choose something you are familiar with, like "John Doe". This works, and your application seems to work fine.

Then, one day, someone names their child Robert'); DROP TABLE Students; -- (little Bobby Tables).

enter image description here

Of course, you don't test your app for names like that, so the security hole that such a name exposes slips through all your testing.

There is an interesting comment here: The Unfalsifiability of Security Claims

It's easy to prove a security hole exists (you just test for a name like the above). It's also easy to prove that a particular hole has been fixed. It's hard to prove no other security holes exist.

1
source | link

When testing, it is very easy to test for what you expect to happen. For example, when filling in a "name" field in a database you will probably choose something you are familiar with, like "John Doe". This works, and your application seems to work fine.

Then, one day, someone names their child Robert'); DROP TABLE Students; -- (little Bobby Tables).

https://xkcd.com/327/

Of course, you don't test your app for names like that, so the security hole that such a name exposes slips through all your testing.

There is an interesting comment here: The Unfalsifiability of Security Claims

It's easy to prove a security hole exists (you just test for a name like the above). It's also easy to prove that a particular hole has been fixed. It's hard to prove no other security holes exist.