API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。
AUTHID CURRENT_USER パッケージでは、現在のユーザースキーマに対して識別子が最初に解決されます。その結果、識別子がどのスキーマに属しているのかをコードの定義が明示していない場合、予期せぬ動作が引き起こされる可能性があります。SYS.PERMISSIONS に対してのみ読み取りアクセスが許可されるようになり、定義済みの権限を変更できません。
CREATE or REPLACE FUNCTION check_permissions(
p_name IN VARCHAR2, p_action IN VARCHAR2)
RETURN BOOLEAN
AUTHID CURRENT_USER
IS
r_count NUMBER;
perm BOOLEAN := FALSE;
BEGIN
SELECT count(*) INTO r_count FROM PERMISSIONS
WHERE name = p_name AND action = p_action;
IF r_count > 0 THEN
perm := TRUE;
END IF;
RETURN perm;
END check_permissions
check_permissions 関数をコールするユーザーがスキーマで PERMISSIONS テーブルを定義する場合、データベースが識別子を解決して、ローカルテーブルを参照します。ユーザーは新しいテーブルに対する書き込み権限を付与されるため、データベースを変更することによって本来付与されないはずの権限を取得できるようになります。