PCES cheat sheet for Python security basics, secure coding, secrets, files, input validation, and exam traps.
Use this cheat sheet for PCES-30-0x Certified Entry-Level Security Specialist with Python after you can already read small Python scripts. The exam lane is not advanced penetration testing. It is entry-level Python safety: validate input, protect secrets, avoid unsafe file handling, understand security terms, and automate without creating new risk.
flowchart TD
S["Scenario"] --> I["What input, file, secret, or permission is at risk?"]
I --> V["Validate or constrain before trust"]
V --> P["Protect secret, path, data, or output"]
P --> E["Preserve evidence and fail safely"]
If an answer makes the script work but leaks data, trusts input, broadens permission, or hides errors, it is usually weaker.
| Lane | Decision rule | Reject when |
|---|---|---|
| Input validation | Check type, length, range, format, and allowed values before use. | The script trusts raw input because it came from a user, file, or API. |
| Secrets | Keep tokens, passwords, and keys outside source code and logs. | Credentials are hard-coded, printed, committed, or stored in plain text. |
| Files and paths | Normalize and constrain paths before opening, writing, or deleting. | User input can escape the intended directory. |
| Hashing vs encryption | Hashing verifies integrity or passwords; encryption preserves confidentiality. | The answer says a hash can decrypt data later. |
| Authentication vs authorization | Authentication proves identity; authorization decides allowed actions. | Login success is treated as permission for every record. |
| Logging and evidence | Log useful events without exposing sensitive values. | Debug logs reveal secrets or raw personal data. |
| Stem clue | Eliminate first | Keep in play |
|---|---|---|
| user supplies a filename | concatenate path and open directly | allowlist, normalize, and restrict to expected directory |
| API key is needed by a script | paste key into source code | environment/config secret with restricted access |
| error handling is required | catch every exception and continue silently | handle expected errors and fail loudly for unsafe states |
| output includes user text | render or print raw content everywhere | escape, redact, or validate based on output target |
| file may contain malformed rows | process everything without checks | validate rows, skip/quarantine bad records, report count |
| script needs elevated access | run as administrator by default | least privilege for the specific task |
| audit is required | delete temporary evidence immediately | preserve relevant logs and redact sensitive values |
| Pattern | Safer instinct |
|---|---|
except Exception: pass |
Catch specific exceptions and report enough context to diagnose. |
open(user_input) |
Resolve and validate the final path before opening. |
print(secret) |
Mask or avoid logging sensitive values. |
eval(input_value) |
Do not execute untrusted strings as code. |
| Writing output files | Write to a temporary file, validate, then replace if safe. |
| Parsing external data | Treat CSV, JSON, HTML, and API responses as untrusted until checked. |
| If the stem says… | Start with |
|---|---|
| “securely store” | secret handling, encryption, access, and logging behavior |
| “validate” | type, range, format, allowed values, and failure behavior |
| “file path” | path traversal, overwrite risk, permissions, and safe directory boundary |
| “identify user” | authentication |
| “allow action” | authorization |
| “prove what happened” | logs, timestamps, actor, action, result, and redaction |
PCES practice should mix Python code reading with security judgment. Drill short snippets and ask: what data is trusted, what permission is broad, what evidence remains, and what could leak?