The Security Mindset & Authorized Testing

Authorization is the whole game

The techniques in this track are neutral. Run a port scan against your own lab and you’re learning; run it against a bank and you’ve committed a crime in most countries — under laws like the US Computer Fraud and Abuse Act or the UK Computer Misuse Act — regardless of whether you “meant well” or caused no damage.

So the first skill isn’t technical. It’s knowing your scope:

• Own it or have written permission. A home lab, deliberately vulnerable VMs (DVWA, Metasploitable), a CTF, or a paid engagement with a signed rules of engagement document.
• Stay inside the lines. The scope defines which hosts, which techniques (some forbid denial-of-service or social engineering), and which time windows are allowed.
• Minimize impact. Authorized doesn’t mean reckless — don’t exfiltrate real data, don’t degrade production, stop and report if you find something critical.

The defender’s three mental models

Beyond ethics, three principles shape how you build and break systems:

graph LR
A["Attacker"] -->|must pass| L1["Network<br/>segmentation"]
L1 --> L2["Authentication"]
L2 --> L3["Authorization<br/>(least privilege)"]
L3 --> L4["Input validation"]
L4 --> L5["Monitoring<br/>& alerting"]
L5 --> D["Data"]
style D fill:#059669,color:#fff

• Defense in depth. Never rely on one control. Stack independent layers so breaching the firewall still leaves the attacker facing authentication, then authorization, then validation, then detection. The diagram above is one such stack.
• Least privilege. Every component, user, and token gets the minimum access it needs and no more. A compromised service with read-only access to one table is a far smaller disaster than one with admin everywhere.
• Assume breach. Design as if the attacker is already inside. Shrink the blast radius, segment aggressively, and log everything so you can detect and contain. This is the heart of zero-trust.

Encode your rules of engagement in code

A professional habit: make the tool itself refuse to act outside the authorized scope. Here a scanner checks every target against an allowlisted CIDR before it would ever send a packet — a guardrail that turns a promise into an enforced control. This runs here (pure parsing, no network):

package main

import (
"fmt"
"net"
)

// authorizedScope is the ONLY range this tool is permitted to touch.
var authorizedScope = mustCIDR("192.168.56.0/24") // a typical lab network

func mustCIDR(s string) *net.IPNet {
_, n, err := net.ParseCIDR(s)
if err != nil {
	panic(err)
}
return n
}

// inScope is the guardrail every action must pass first.
func inScope(target string) bool {
ip := net.ParseIP(target)
return ip != nil && authorizedScope.Contains(ip)
}

func main() {
targets := []string{"192.168.56.10", "192.168.56.250", "8.8.8.8", "10.0.0.1"}
for _, t := range targets {
	if inScope(t) {
		fmt.Printf("%-15s ✓ authorized — scanning\n", t)
	} else {
		fmt.Printf("%-15s ✗ OUT OF SCOPE — refusing\n", t)
	}
}
}

8.8.8.8 and 10.0.0.1 are refused before any probe is sent. Building this check into your tooling is how you avoid the career-ending mistake of scanning the wrong network.

Responsible disclosure

When you find a real vulnerability in software you don’t own, the ethical path is coordinated disclosure: report it privately to the vendor (look for a security.txt, a security contact, or a bug-bounty program), give them a reasonable window to fix it (90 days is a common norm), and only then coordinate public disclosure. This protects the users running that software while still ensuring the flaw gets fixed and known. Dumping a working exploit publicly with no warning endangers everyone.

See also

• Why Go for security — the language’s fit for tooling.
• Building security tools — shipping responsibly, with rate limits and logging.
• Input validation & injection defense — defense in depth at the code level.
• Authentication & authorization — least privilege in practice.

Next: how to actually build and ship a tool — building security tools.

Related topics