<div dir="ltr">David,<div><br></div><div>I understand the reasons behind seeing authorization checks at the runtime layer as something that just adds, without any harm in the worst case (all of this putting the maintenance cost and other arguments aside.)</div><div><br></div><div>My concern is more about the general security principles underpinning the idea. We will probably agree that half-barriers are not barriers, and might cause a false sense of security. If we have authorization checks at the runtime level, they must be comprehensive, coherent and well-maintained. Their availability suggests that mixing high-level checks with runtime-level ones can be part of a good security design in modern application development. For the reasons that we've been discussing, I'm not convinced of that. And even when subtle, I prefer the runtime not to make the suggestion. If you still want it, you can go ahead with instrumentation; but it's clear that for the runtime developers that is a workaround and not a desirable security design.</div><div><br></div><div>What I mean by splitting responsibility is that application developers can use a mix of high and low level checks, at different layers, with more complexity. As Sean said, letting the unauthorized user to move towards the edge of the action is more risky. We can lose sight of workarounds and holes with the additional attack surface and complexity that comes at a lower layer. What I want to stress is the value of clarity, simplicity and division of responsibilities as a general security principle.<br></div><div><br></div><div>Martin.-</div><div><br></div></div>