Secure AES IV with static salt I have an (offline) shared secret key (symmetric) which is used to encrypt/decrypt data.
Now this data belongs to a specific user which is known on the backend and frontend. My idea was to use the username/id as salt. But for AES we only have the iv.
Doing this would make sure that the data on the frontend can only be encrypted if the correct user is logged in, because without the correct salt/iv. The data would be nonsense.
But this iv would not be random anymore.
So do you have a suggestion for me on how to deal with the problem? Also, the secret key and the username/id is the only thing both endpoints know.
You did not mention the mode of operation for any block cipher that is necessary.

CBC mode requires the IV random and unpredictable so this is not your way.

CTR mode requires an $(IV,Key)$ pair never occurs more than once. One must never use the same $(IV,key)$ pair again, otherwise, confidentiality is lost.
CTR mode generally uses 96-bit nonce and 32-bit counter to form the Initial value. If the nonce reoccurs and counters repeat then these blocks can be revealed with crib-dragging. The nonce can be chosen randomly that will have a 50% probability of collision after $2^{48}$ random nonce generation. Counter/LFSR-based nonce generation is also recommended by NIST.


CTR mode can be a solution for you.
The above modes don't provide you more than confidentiality. We can, and we should go more;

GCM provides you confidentiality, integrity, and authentication. Since GCM uses the CTR mode for encryption, you will have the same (IV, key) reuse problem.
If the IV has 92-bit length then $J_0 =IV || 0^{31} ||1$ is passed to the CTR mode as the IV where the 32 bits is used as a counter which starts  form $1$. SO if you reuse the same IV under the same key, you will have the same problem in the CTR mode.

XChaCha20-poly1305 is ChaCha20 with an extended nonce that we can use random nonce more securely. It has 192-bit nonce sizes and one has a collision with 50% probability once generates $2^{96}$ random nonces under the same key. Though this has the same $(IV,key)$ problem the probability of getting it is not-going-to-happen.

There is also AES-GCM-SIV mode. This is nonce-misuse resistant and even the IVs are the same the mode will only leak that the messages are the same. This requires additional passes over the data.


Therefore, one can use AES-GCM-SIV to mitigate all possible problems or use xChaCha20-poly1305.
For the user, you should note that the IV/nonce of the encryption is never meant to be secret. They can be stored, usually prepended, with the ciphertext. During the client-side encryption, they can be created. Therefore the user doesn't need to know anything about the IV/nonce after the encryption, the server can store them with the ciphertext. The user only needs the secret key and must keep it secret all the time.