How consider row-level security for tables that host foreign-keys

Question

Introduction

I'm using a role-based security and layered schemas to control access to hosted data.

More concretely, I'm using a "api" schema that hosts views to the underlying "core" schema. In doing so, let me determine which columns to expose to the "api".

The row-level security is specified using policies that match the row using a function that includes the following snippet:

select current_setting('auth.user_id', true)
   into strict user_id;

The scope of the security thus far are the tables that hold information about a user (e.g., users, user_profiles, and projects).

Question

Given this security design, how should I think about the tables that host relationships between data tables, e.g., to host N:N relationships and the like. Thus far, the only driver for me to alter the security of FKs references is to do what minimum it takes to enable the permitted inserts and updates of the "primary" data of interest (e.g., users, and projects).

Am I creating a security vulnerability by not including the tables that essentially serve only to link different tables?

On a related note, I have read in a few places about policies for "references", they seem like they should be in scope in the security design, I'm just not sure how so.