I'm going to be the contrarian here and at least ask whether the right answer is "don't do any of these options".
To see why, consider a hypothetical world where we do one of the above options, and a site sets whatever config is necessary to disable APPEND_SLASH behavior in the admin. The very next thing we're going to get is a report to the security address saying there's a detectable timing difference between what we do to hide a real app/model from a user with admin-access-but-not-to-that-model/app, and what we do when that app/model genuinely doesn't exist, and in order to properly hide apps/models could we please address that? (and if we do end up taking one of the above options, please consider this my report of this vulnerability, as I can pretty much guarantee that 404'ing a nonexistent app/model will be faster than finding it, resolving a URL into it, and doing the associated permission check) And this will never end. For a user who already has been granted admin access, there likely *always* will be some detectable difference between the admin's behavior with respect to a model/app that isn't present versus one that is present but for which the user is not authorized. In an app with the complexity of the admin, there are just too many possible behavioral-difference vectors that people will be able to come up with, and we'll never be able to close them all reliably. So what I'd really like us to do here is pause and consider what kinds of guarantees we can really commit to. Some are obvious and good and we already do or try to do them -- you shouldn't be able to access/modify/delete things you haven't been granted access to, you shouldn't be able to escalate your own privileges, you shouldn't be able to XSS the admin, etc. But it's not at all clear to me that "the existence or nonexistence of apps/models to which they don't have access is undetectable to an admin user" is one of the guarantees the admin should make. I understand the rationale, but I'm not sure the threat it wants to be securing against is one we reasonably *can* secure against. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg_1QRhht3eSD29AJ25Cbkp%2BfbCxyOi7GdhYpfzcEkmDbQ%40mail.gmail.com.
