Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
This is better known as AuthZ or Authorization (rather than authentication, what's the difference).
And realistically the solution is to always verify authorization at the service who owns the resource. In the case here that would be the service layer. If the web layer is really a composite service you still wouldn't make the check there. Only if it saved it own resource you could make check, and you should only be checking for the resource as it is owned/known by that service. Don't verify other services' permissions, those can change over time.
I know this is fairly complicated, which is exactly why services like Authress exist to solve this problem.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
This particular security error also appears in the OWASP Top 10 as Broken Access Control (owasp.org/www-project-top-ten/2017...), along with recommendations on remediation such as: introducing a resource identifier mapping layer (typically generated at login and held in the web session) that only maps permitted resource keys (typically UUIDs) to true values (which now remain entirely server side); or as Warren notes above, delegating authorization checks to individual services (if that's how your server side works), that understand their specific context and how it relates to callers permissions (typically provided in a JWT).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is better known as AuthZ or Authorization (rather than authentication, what's the difference).
And realistically the solution is to always verify authorization at the service who owns the resource. In the case here that would be the service layer. If the web layer is really a composite service you still wouldn't make the check there. Only if it saved it own resource you could make check, and you should only be checking for the resource as it is owned/known by that service. Don't verify other services' permissions, those can change over time.
I know this is fairly complicated, which is exactly why services like Authress exist to solve this problem.
This particular security error also appears in the OWASP Top 10 as Broken Access Control (owasp.org/www-project-top-ten/2017...), along with recommendations on remediation such as: introducing a resource identifier mapping layer (typically generated at login and held in the web session) that only maps permitted resource keys (typically UUIDs) to true values (which now remain entirely server side); or as Warren notes above, delegating authorization checks to individual services (if that's how your server side works), that understand their specific context and how it relates to callers permissions (typically provided in a JWT).