Security Cheat Sheets — OWASP, Nmap & Regex

01 · THE REFERENCES

Defend & assess

The references practitioners actually keep open. OWASP is the one to read before writing security-sensitive code; the other two are lookups you reach for while working.

• OWASP Cheat Sheet Series ↗The definitive, community-maintained collection of secure-coding cheat sheets — authentication, injection, XSS, and dozens more. The industry standard.cheatsheetseries.owasp.org
• Nmap Cheat Sheet ↗Scan types, host discovery, and NSE scripting for the network scanner every pentester and admin relies on.stationx.net
• Regex Cheat Sheet ↗Essential for log analysis, input validation, and detection rules — regular expressions decoded at a glance.quickref.me

02 · SECURE CODING

The handful of principles behind most OWASP guidance

Separate code from data

Injection flaws, whether SQL, command, or otherwise, all share one shape: attacker-controlled text ends up being interpreted as instructions. The fix is structural rather than clever. Parameterized queries send the query and the values along separate channels, so the database never parses user input as SQL. No amount of escaping or filtering is as reliable, because escaping depends on getting every case right forever while parameterization removes the possibility.

Validate against an allowlist

Blocking known-bad input fails because the set of bad input is unbounded and attackers are creative about encodings. Defining what is acceptable and rejecting everything else fails safely, since anything unanticipated is refused rather than admitted. This applies to file types, redirect targets, and identifiers as much as to text fields.

Encode on output, for the right context

Cross-site scripting is fundamentally an output problem. The same string is harmless in one place and dangerous in another, so encoding has to match where the value lands: HTML body, an attribute, a URL, or JavaScript each need different treatment. Encoding once on input and assuming it is safe everywhere afterwards is a common and unreliable pattern.

Never invent your own cryptography

Use vetted libraries and current recommendations for password hashing and encryption. Homegrown schemes fail in ways that are invisible until disclosed, and OWASP's guidance is specific about which algorithms and parameters are currently considered sound.

03 · SCANNING

What Nmap tells you, and what it does not

Nmap answers a narrow question well: which hosts are reachable, which ports respond, and what the things behind them appear to be. It is the first step of assessment and of a great deal of ordinary systems administration, because knowing what is actually exposed is the foundation of securing it.

Two limits are worth holding onto. Version and operating-system detection are inferences from observed behavior, not facts, so treat them as leads rather than conclusions. And a service being open says nothing about whether it is vulnerable. A clean scan is not a clean bill of health, and a scary-looking open port is often a correctly configured service doing its job.

Scan intensity also matters. Aggressive timing and broad port ranges generate a lot of traffic, can disrupt fragile devices, and will show up in monitoring. On systems you are authorized to test, that is a conversation to have with whoever operates them first.

04 · REGEX IN SECURITY

A sharp tool that cuts both ways

Regular expressions appear everywhere in security work: parsing logs, writing detection rules, and validating input. They are excellent at the first two. The third deserves caution, because a regex that is meant to accept only valid input is a security control, and a subtly permissive pattern becomes a bypass.

There is also a denial-of-service risk specific to regex. Certain patterns, particularly those with nested quantifiers applied to overlapping alternatives, can take exponential time on inputs crafted to trigger backtracking. A validation rule intended to protect a service can therefore become the thing that stalls it. Keeping patterns simple and anchored, and testing them against deliberately awkward input, mitigates most of this.

The classic advice holds too: do not use regular expressions to parse structured formats like HTML or XML. Use a real parser. Nested and recursive structures are exactly what regular expressions cannot reliably handle, and security bugs cluster in the gap between what a pattern matches and what a parser accepts.

05 · FAQ

Frequently asked questions

Are these security cheat sheets free?

Yes. The OWASP Cheat Sheet Series is a free, community-maintained open project, and the Nmap and regex references are free web pages. None require an account or payment.

Is it legal to scan a network with Nmap?

Only with authorization. Scanning systems you own or have explicit written permission to assess is fine, while scanning third-party infrastructure without permission is unlawful in many jurisdictions regardless of intent. Practice on your own machines or a local virtual lab.

What is the best defense against SQL injection?

Parameterized queries, also called prepared statements. They send the query structure and the values through separate channels so user input is never parsed as SQL. This is structurally safer than escaping or filtering, which depend on handling every case correctly forever.

Should I validate input with a blocklist or an allowlist?

An allowlist. Defining exactly what is acceptable and rejecting everything else fails safely, whereas blocking known-bad input is unbounded work because attackers can vary encodings and find cases you did not anticipate.

Can a regular expression be a security risk?

Yes, in two ways. A pattern used for validation that is slightly too permissive becomes a bypass, and certain patterns with nested quantifiers can take exponential time on crafted input, stalling the service they were meant to protect. Keep validation patterns simple and anchored, and use a real parser for structured formats.