Most teams treat a security assessment as something that happens to them. An outside report arrives, with findings ranked by how serious they are, and engineering spends the next few months working down the list. That is a fair process, but it is not the only one, and waiting for one assessment a year means actual gaps sit open for months between each review. A structured assessment run by your own team, on a regular schedule, catches most of the same issues earlier, and far more cheaply. Here is the plan we follow.
Trying to check the whole application's security in a single pass produces a report nobody can actually act on. Break the work into layers that match how attacks really happen and how fixes really get assigned. The network and web layer, headers, browser security policy, cross origin rules, encryption. How input is handled and whether requests can be trusted. The data layer, injection risks, how data is accessed. Login and session handling. Who is allowed to do what. Each layer has a different owner, a different way to fix it, and a different way to check the fix, and keeping them separate is what makes the final report something each team can actually work through.
Start by testing the running application the way an outsider would, with no access to the source code. Try reflecting input back at the page. Try slipping markup into a stored field. Check whether security headers are present and strict. Look for obvious gaps in login. This tells you what is actually true today, from the outside. Then move to reading the actual code behind whatever you tested, and behind anything you could not fully confirm from the outside alone. Doing both matters, since testing from the outside alone can miss a defense that exists but simply never triggered on your specific tests, and reading code alone can miss actual behaviour that does not match what the code appears to say.
A textbook weakness sitting behind an admin only report filter, and the exact same kind of weakness sitting on a page anyone on the internet can reach, are not the same level of risk, even though an automatic scanner would label them the same way. Grade every finding by who could actually use it, what they would need to know or have to do so, and what they would actually gain. This is what turns a report with two hundred scanner findings into a list of twenty that engineering will genuinely work through.
The single most common mistake across repeated assessments is treating a previous report's "fixed" label as still true today. Code keeps changing. A gap closed eighteen months ago can be quietly reopened by an unrelated change that happens to touch the same part of the code. Every new assessment should check old, supposedly closed findings again, not only look at what is new, since a review that only looks forward will eventually rediscover an old weakness the hard way, in production.
It is hard to judge whether your protection against request forgery is good purely by looking at it on its own. It is much easier to judge it against a written standard, what a popular framework does by default, what a recognised checklist asks for at the level you are aiming for. Comparing your own setup, layer by layer, against an outside reference turns a vague feeling of "we think we are fine" into a specific, defensible answer about exactly where you stand, and exactly what closing the gap would actually take.
A report that only lists technical findings serves engineering but tells leadership nothing useful about business risk or what fixing it will cost. A report that is only a short summary tells leadership the headline but gives engineering nothing to actually act on. Write both. A plain summary stating overall risk in business terms, and a detailed, technical section per layer that engineering can turn directly into tickets.
Findings that do not get fixed right away are the ones most likely to be forgotten the moment the report gets filed away. Turn every open item into a tracked task with a clear priority and a clear owner, not a single line in a document nobody opens again until the next assessment reminds them it is still sitting there.
Maybeach Tech runs structured assessments, both internal and external, for engineering teams who want a clear, prioritised picture of where they actually stand. Get in touch and let us scope yours.
