@MeriemA16758953 I am following the issue and I can see that our support team passed you on to our  Ask the Expert - Basic Access Control with Elisha Tanikonda and Rachit Agarwal SME's.

I am just updating the post with the latest status, and also to advise you that we are waiting for further SME input based on your recent confirmation that you have followed all the recommended steps but that the issue still remains.

Explanation given by GCS:

Pega Platform™ includes the ability to invoke server functionality through activities, which are JavaScript APIs with wrapper rules. To improve the overall security of the application, only allow authorized access to these activities through JavaScript or AJAX code.

Introduced in Pega Platform version 8.5, BAC is a security feature that protects your application from unauthorized access.

BAC protects your application by verifying requests at the application layer and provides additional request verification when you use autogenerated controls.

 pzSecureFeature:

• Default value: True when 

• the portal is not Dev Studio, App Studio, Admin Studio, or Prediction Studio. 

AND 

• the client is not mobile or hybrid. 

In other words, the access control check is not done when the client is using Dev Studio, App Studio, Admin Studio, or Prediction Studio and the client is mobile or hybrid. The check is done everywhere else. 

• Behavior when true: Application level checking is on. When an access violation is found, a security alert is logged that says "Unregistered request encountered"; default behavior. 

• Behavior when false: Application level checking is off. 

pyShowSecureFeatreWarnings :

• Description: Controls display of a warning to the end user 

• Default value: False 

• Behavior when true: When an access violation is found and pyBlockUnregisteredRequests is false, a Pega warning is displayed to the user saying "URL tampering vulnerability detected." 

• Behavior when false: The browser console displays a log to identify the JavaScript code that triggered the request. 

pyBlockUnregistredRequests = false

• Description: Controls the HTTP response 

• Default value: pxProcess.pzProductionLevel ≥ 2 

Note: The default value is False when the production level is < 2. When the production level is changed to 2, the value changes to True. 

• Behavior when pxProcess.pzProductionLevel ≥ 2: When an access violation is found, the server responds with HTTP status 403, and the user sees a browser error saying the request is forbidden. Security alert SECU0019 appears on the security alert log. 

• Behavior when pyBlockUnregisteredRequests is false: The request is processed normally; the server does not respond with HTTP status 403. 

Note: 

Pega Platform version 8.5 introduced this feature. When pyBlockUnregisteredRequests is enabled in development, the application development team can detect and respond to any problems with unauthorized or unregistered requests well ahead of application staging and production deadlines. In Pega Platform versions 8.5.6 and higher, 8.6.3 and higher, and 8.7 and higher, the when rule blocks unauthorized requests by default at production level 2 (Development/Test) or higher. In versions prior to 8.5.6, 8.6.3, and 8.7, the when rule blocks unauthorized requests by default at production level values of 4 (4 is Staging, 5 is Production) or higher. See Verifying requests when using custom controls for registration steps for the user request based on the various scenarios. As a security best practice, ensure that you properly enable pyBlockUnregisteredRequests to return a value of True to block unregistered requests.  

https://docs.pega.com/bundle/platform-88/page/platform/security/bac.html

More detail:

 If pzSecureFeature=true -- > : Application level checking is on. When an access violation is found, a security alert is logged that says "Unregistered request encountered"; default behavior. Security alert log if pyBlockUnregisteredRequests=true --> You will be able to catch http responses and able to see output on the dev tool console. Security alert log + console logs and you will be able to see which function/feature not working and it might help to identify easier BAC issues.

-----------------------------------

You had follow up question  because the behavior on  application post upgrade is not like GCS explained:

IE  "if pzSecureFeature=true -- > : Application level checking is on. When an access violation is found, a security alert is logged that says "Unregistered request encountered"; default behavior. Security alert log"

Instead, we have no alert logged, even though the application level checking is on

------------------------------------------------------

Answer provided by SME ON 15 November:

So, when pyBlockUnregistredRequests is set to true, Pega would try to check if the request is valid request or not. If not, it will throw a 403 alert(you can check the network request in the Dev tools) and user will be blocked with their work.

When it is set to false, Pega would not throw any 403 alert(in the Dev tools) and users will not be blocked with their work. 

However, in both these situations, Pega would throw a Secu0019 ALERT as Secu0019 does not depend on the when rule. 

I have not came across scenario where even though a it is a valid BAC scenario, and still this does not gets printed in the logs. Can you can please let us know  if this is happening across all environments or if in one specific environment. 

Also  users are best advised to be latest UI-KIT version. For 8.8.4, it is UI-KIT 15:01.

Ensure that you are testing the scenario by directly logging as an End User.

If you login to Dev Studio and then launch the End User portal, BAC feature will not turn on (based on the logic in pzSecureFeatures when rule).

In case you are on a multi-node environment (whilst testing through as an EndUser),  please ensure to check the Alert Security logs in all the nodes. Alternatively, login using the direct node URL and check for the logs for that node.

In case the suggestions do not help, we will continue the investigation via the support ticket, we see that you have an active INC.

---------------------------------------------------------------------------------------

As it sounds like the issue is not behaving as instructed by our SME's I am checking whether you need to continue to work with GCS in the open support ticket INC-B47252