Episode 30 — Perform Manual Function Reviews to Catch Design Flaws Automated Tools Miss
When you first hear about security reviews, it is natural to assume that automated scanners and tools will do most of the heavy lifting, because computers are fast and can find obvious mistakes at scale. Automated tools are useful, but they have limits, especially when the problem is not a known vulnerability pattern but a design flaw hidden inside normal, correct-looking functionality. Many of the worst security failures are not caused by a single broken line of code; they are caused by a feature that works exactly as implemented, but the implementation does not match the intended security behavior. Manual function reviews are a way to examine what a system does, how it does it, and whether the behavior aligns with the architecture’s trust boundaries, authorization rules, and data protection goals. The word manual can sound intimidating, but it simply means a human carefully evaluates functions and workflows with a security mindset instead of relying on pattern matching. This episode explains how manual function reviews help catch design flaws that automated tools miss, what you should look for as a beginner, and how to turn review findings into clearer requirements and safer architecture decisions. The goal is to teach you to recognize risky behavior that looks normal, because that is where design flaws often hide.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
A manual function review starts from the idea that every function in a system is a promise about behavior. A function might be as obvious as create account, reset password, upload file, or generate report, or it might be less obvious, like synchronize data, reprocess events, or retry a failed job. Each function interacts with identity, data, and boundaries, even if it is not labeled as security. Automated tools might flag known dangerous functions or insecure configurations, but they cannot reliably judge whether a particular function is appropriate for a particular role, whether its outputs leak too much, or whether its workflow can be abused. Manual review fills that gap by asking questions about intent, trust, and consequences. For example, does a reporting function return only data the user is authorized to see, or does it return everything and rely on the user interface to hide parts? Does a password reset function properly prove identity, or can it be triggered with minimal information? Does an administrative function have safeguards against misuse, such as requiring strong authorization and creating audit records? These are behavioral questions, and manual review is about systematically asking them across critical functions. The key is that you are reviewing how the system behaves, not just whether it has a security tool enabled.
A useful way to approach manual function review is to identify which functions are security-critical, meaning that if they are misdesigned, the impact could be large. Functions that change identity state, like enrollment, authentication, password reset, or role assignment, are security-critical because they affect who the system thinks someone is. Functions that access or modify sensitive data are security-critical because they affect confidentiality and integrity. Functions that trigger privileged actions, like configuration changes or approvals, are security-critical because they can alter system behavior or authorize important operations. Functions that export, share, or integrate data are security-critical because they often expand exposure. Functions that affect availability, like bulk processing or job scheduling, can be security-critical because they can be abused for denial of service. As a beginner, you do not need to review every function equally; you start with the ones that touch trust boundaries and high-value assets. Once you map functions to risk, you can review more efficiently. Manual review is not about reading every line; it is about focusing human attention where it matters most.
One of the most common design flaws manual function reviews find is missing or inconsistent authorization. Authorization is easy to get wrong because it is often repeated across many functions, and developers may implement checks differently in different places. Automated tools may not notice that a function lacks an authorization check if the function looks legitimate, and there may be no obvious insecure keyword to flag. A manual reviewer asks, who is allowed to call this function, and where is that enforced? If enforcement is only in the user interface, that is a weak design because requests can arrive through other paths. Another red flag is when a function decides access based on client-provided data, such as trusting a user identifier in a request without verifying ownership. Manual review also checks that authorization is not just role-based but context-aware when needed, such as ensuring users can only modify objects they own. These issues are design flaws because they reflect incorrect boundary decisions, not just coding bugs. Finding them early can prevent serious breaches because authorization failures often lead directly to data exposure or unauthorized changes.
Data exposure through normal outputs is another area where manual review is especially valuable. Many systems leak data because they return more than necessary in responses, reports, exports, or logs, and the leak is not obvious to automated tools. A function might return an entire record object even when the client only needs a few fields, and those extra fields may include sensitive information. A search function might reveal data through autocomplete, sorting, or error messages that include internal identifiers. A reporting function might allow users to filter data broadly and accidentally access records outside their scope. Manual review asks, what data is produced by this function, who receives it, and does that match the least exposure principle? It also asks whether sensitive data is handled safely when errors occur, such as whether error responses contain stack traces or internal details that could aid attackers. You can often detect these design flaws by thinking about what an attacker would learn from a response, even if the function seems to work correctly. This is why manual review focuses on behavior and intent rather than just vulnerabilities. In architecture, controlling data exposure is one of the most important goals.
Workflow integrity is another class of design flaw that manual function reviews can reveal, especially in multi-step processes. Many systems rely on sequences like request, approve, and execute, and security depends on those sequences being enforced. A manual review examines whether the system actually enforces the sequence or whether steps can be skipped, repeated, or performed out of order. For example, can a user access a resource before completing required verification, or can someone approve their own request when separation is expected? Can a function be invoked directly to execute a privileged action without passing through the intended approval gate? Automated tools are not good at understanding workflow meaning, because meaning is contextual and tied to business rules. Manual reviewers can evaluate whether workflows preserve trust, prevent fraud, and maintain consistent state. They also look for race conditions in behavior, such as whether two requests can be timed to cause inconsistent outcomes, even if the system is not under attack. While deep concurrency analysis can be advanced, the beginner-level idea is simple: if the design relies on order, the functions must enforce order. Manual review makes you look for shortcuts and bypasses.
Identity-related functions deserve careful manual review because they are often abused, and small design mistakes can have big consequences. Authentication flows, password resets, account recovery, and session management all determine whether attackers can pretend to be legitimate users. A manual review checks whether the system requires enough proof before changing identity state, such as resetting credentials or changing contact information. It also checks whether sessions are terminated correctly, whether sensitive actions require re-verification, and whether accounts can be protected against repeated guessing or abuse. Even without discussing specific technologies, you can review whether the behavior aligns with secure expectations, such as rejecting actions when identity is not confidently established. Another subtle issue is privilege assignment, such as how roles are granted and how role changes are audited. If a function allows role changes without strong controls, an attacker who gains any access might escalate privileges quickly. Manual review is often the only way to notice these design issues because they are not always code-level vulnerabilities; they are about choosing the right identity behaviors. In architecture, identity is foundational, so mistakes here ripple everywhere.
Manual function review also helps you evaluate how functions behave under failure, because safe failure is a security requirement that tools often cannot judge. If a dependency is unavailable, does the function deny sensitive actions, or does it allow them because it cannot verify something? If a validation step fails, does the function stop cleanly, or does it partially complete and leave the system in an inconsistent state? If an action is denied, does the function respond in a way that reveals internal details or confirms sensitive information to unauthorized users? These are behavior-driven questions that are hard for automated tools to answer without deep context. In manual review, you explore failure modes as part of understanding function risk, because attackers often exploit edge cases where systems behave differently. You also consider whether failures create opportunities for denial of service, such as functions that retry endlessly or allocate large resources before performing authorization. By evaluating failure behavior, you catch design flaws that can become both security and reliability incidents. Architecture that fails safely is architecture that can be trusted under stress.
Another advantage of manual function review is that it can reveal architectural drift, where different parts of a system follow different security patterns over time. Automated tools might catch obvious issues, but they may not highlight that one service uses strict authorization while another service is permissive. Manual review can compare similar functions across different components and ask why they differ. If the difference is intentional, it should be documented and justified; if it is accidental, it is a gap. Drift often happens when teams move fast, copy patterns inconsistently, or introduce new components that do not follow the original architecture standards. By doing manual reviews periodically, you can keep security behavior consistent and reduce the chance that attackers find the one weak path. This is especially important in distributed systems where many interfaces exist. Consistency is a major part of security architecture quality, and manual review is a practical way to enforce it. When you see drift, you can respond with architectural guidance, shared patterns, and clear requirements.
The output of a manual function review should be actionable, meaning it should lead to clear remediation or clearer requirements. If you find that authorization is missing in a function, you document the gap, describe the intended behavior, and specify where enforcement should occur. If you find that outputs include unnecessary sensitive fields, you recommend data minimization requirements and define what should be returned. If you find workflow bypasses, you define sequence enforcement requirements and clarify which roles can perform which steps. It is also important to tie findings back to threats and impact, because that helps prioritize fixes and helps stakeholders understand why the changes matter. Manual review findings are most powerful when they can be validated later through functional tests, which closes the loop between design, implementation, and verification. In other words, manual review should not produce vague warnings; it should produce behavior expectations. This keeps the review from becoming an opinion contest and turns it into architecture improvement. The goal is to make the system’s promises match its behavior.
The main idea to carry forward is that automated tools are great at spotting known patterns, but they are not good at judging whether a function’s behavior is appropriate within a specific architecture and trust model. Manual function reviews fill that gap by evaluating intent, boundaries, authorization, data exposure, workflow integrity, identity behaviors, and safe failure. For beginners, the skill is learning to ask the right questions about who can do what, what data is involved, what assumptions are being made, and what happens when things go wrong. When you do this consistently, you catch design flaws early, before they become incidents, and you improve the architecture by turning findings into testable requirements. Manual review is not about mistrusting developers; it is about recognizing that complex systems can behave in surprising ways, and that security depends on careful alignment between design intent and real behavior. Over time, this practice strengthens the architecture because it reduces hidden gaps and increases consistency. That is how you catch what automated tools miss: by using human judgment to evaluate security behavior as part of how the system actually functions.
