Comment by eithed | Hacker News Reader

Comment by eithed | Hacker News Reader

We're using similar approach in PHP application by facilitating https://github.com/spaze/phpstan-disallowed-calls

In essence we have defined within each domain: a) Public folder with code that other domains can use b) domain folders (src and infra) with code that only given domain can use. This way developers know not to change public contracts for a (or if they do change them they do understand they're changing public code) be it method signatures or interfaces and are free to refactor b, because these classes should not be publicly accessible and can change at any time. Even extending classes defined this way is disallowed.

This becomes helpful when operating within confines of monolith application, but with different teams owning different parts of the application. Trying to use non-public part of each domain will be prevented on commit level (developers will not be able to commit their work) rather than run level though

Letting a static analyzer do these checks is a sane approach! The runtime detection of code files is really weird and would fail with bundling etc.

Yes :) but given that OP does the checks at runtime thought I'd give that disclaimer

Runtime is important if security matters. Assume an attacker has already compromised your program - how much damage can they do? If you check at runtime you can prevent the compromised code from calling your functions. Well maybe, we don't know what code was compromised or how it was, but many compromises are a buffer overflow that only runs a few hundred bytes of code (overflow more than that and you clobber something else important to the attack and so the whole fails) and so the attacker needs to quickly call some sensitive function so if that sensitive function is checking the attack can't do anything.

I've been thinking about the above for a while, but I have no yet figured out how to put it into practice. I'm also not sure how much value it would have against a real world attack. It seems like it should work but security is often weird.

Thinking about this scenario I'd suppose disabling features would be the way to go - disabling individual methods doesn't look feasible and I imagine that it should be done at the configuration level (what I mean here is that you need an easy and quick way to switch the feature flag, rather than recompiling/redeploying). But then the code would have to be built as well to support such feature.

Reply on news.ycombinator.com