> The zero-trust security model assumes breach as the default phenomenon and therefore, it advocates verifying every request with all possible options available to ensure the legitimacy of the request. It also emphasizes following the principle of least privilege access to limit access to the system for only the functions requested even though the elevated privilege might be available for the caller.
> Zero-trust and least privilege access are fundemental principles to ASPSecurityKit design. Few examples:
> 1. As you apply ASPSecurityKit’s ProtectAttribute on the base controller (or the base service in ServiceStack) or as a global filter, it instantly begins guarding all operations of your web application with a multi-stage security pipeline that involves, among other things, XSS validation, authentication, multi-factor, authorization. All these checks are necessary unless you disable one or more for specific operations.
> 2. Following the same principles, activity-based, data-aware authorization components enforce that to execute an operation, the caller must possess its corresponding permissionCode, and any existing data being referred for the operation must also have been permitted. You can selectively exclude operations and data from these checks, but the default is to guard everything.
The user verification, user suspension and entity suspension checks are designed to block every incoming requests if the corresponding check fails, and give you tools and control to explicitly exclude certain operations (of your choice) from the check.
> The zero-trust security model assumes breach as the default phenomenon and therefore, it advocates verifying every request with all possible options available to ensure the legitimacy of the request. It also emphasizes following the principle of least privilege access to limit access to the system for only the functions requested even though the elevated privilege might be available for the caller.
> Zero-trust and least privilege access are fundemental principles to ASPSecurityKit design. Few examples:
> 1. As you apply ASPSecurityKit’s ProtectAttribute on the base controller (or the base service in ServiceStack) or as a global filter, it instantly begins guarding all operations of your web application with a multi-stage security pipeline that involves, among other things, XSS validation, authentication, multi-factor, authorization. All these checks are necessary unless you disable one or more for specific operations.
> 2. Following the same principles, activity-based, data-aware authorization components enforce that to execute an operation, the caller must possess its corresponding permissionCode, and any existing data being referred for the operation must also have been permitted. You can selectively exclude operations and data from these checks, but the default is to guard everything. The user verification, user suspension and entity suspension checks are designed to block every incoming requests if the corresponding check fails, and give you tools and control to explicitly exclude certain operations (of your choice) from the check.
...
https://aspsecuritykit.net/docs/article/introduction/#zero-t...