Java | 再帰のセキュリティ上の注意点

再帰のセキュリティ上の注意点（後半）

前半では、再帰が持つ「きれいさ」と同時に潜む危険として、 無限再帰、深さの暴走、計算量の爆発、スタックトレースによる情報漏洩などを整理しました。 後半では、それらにどう対策するか、そして「安全な再帰の書き方」を具体的なコードとともに掘り下げていきます。 読者が「再帰を怖がる」のではなく、「危険を理解したうえで安全に使いこなす」ことを目標にします。

深さ制限を設計するという発想

再帰の最大のリスクは「深さが入力に依存する」ことです。 そこでまず考えるべきなのが、「どこまで潜ってよいか」を決めることです。 これは、ツリー探索やディレクトリ走査、JSONパースなどで特に重要になります。

例えば、ディレクトリ走査に深さ制限を設けるコードを考えてみます。

public static void scan(File dir, int depth, int maxDepth) {
    if (depth > maxDepth) {
        System.out.println("Max depth reached: " + dir.getPath());
        return;
    }

    File[] files = dir.listFiles();
    if (files == null) return;

    for (File f : files) {
        if (f.isDirectory()) {
            scan(f, depth + 1, maxDepth);
        } else {
            System.out.println(f.getPath());
        }
    }
}

public static void scan(File dir, int depth, int maxDepth) {
    if (depth > maxDepth) {
        System.out.println("Max depth reached: " + dir.getPath());
        return;
    }

    File[] files = dir.listFiles();
    if (files == null) return;

    for (File f : files) {
        if (f.isDirectory()) {
            scan(f, depth + 1, maxDepth);
        } else {
            System.out.println(f.getPath());
        }
    }
}

このコードでは、呼び出しごとに depth を増やし、 maxDepth を超えたらそれ以上潜らないようにしています。 重要なのは、「深さを意識しているかどうか」です。 深さ制限は、攻撃者が異常に深い構造を送り込んだときの最後の防波堤になります。

再帰を非再帰に置き換えるという選択肢

セキュリティとパフォーマンスの観点から見ると、 「再帰をやめてループとスタックで書き直す」という選択肢は非常に強力です。 特に、外部入力に対して深い再帰を行う場合、非再帰化は真剣に検討すべきです。

ツリー構造の探索を例に、再帰版と非再帰版を比較してみます。

再帰版は次のような形でした。

public static void dfs(Node node) {
    System.out.println(node.name);
    for (Node child : node.children) {
        dfs(child);
    }
}

public static void dfs(Node node) {
    System.out.println(node.name);
    for (Node child : node.children) {
        dfs(child);
    }
}

これを非再帰にすると、次のようになります。

import java.util.Stack;

public static void dfsNonRecursive(Node root) {
    Stack<Node> stack = new Stack<>();
    stack.push(root);

    while (!stack.isEmpty()) {
        Node node = stack.pop();
        System.out.println(node.name);

        for (int i = node.children.size() - 1; i >= 0; i--) {
            stack.push(node.children.get(i));
        }
    }
}

import java.util.Stack;

public static void dfsNonRecursive(Node root) {
    Stack<Node> stack = new Stack<>();
    stack.push(root);

    while (!stack.isEmpty()) {
        Node node = stack.pop();
        System.out.println(node.name);

        for (int i = node.children.size() - 1; i >= 0; i--) {
            stack.push(node.children.get(i));
        }
    }
}

ここで深掘りしたいポイントは、 「Javaのコールスタックではなく、自分で管理するスタックを使っている」という点です。 これにより、スタックオーバーフローのリスクを大幅に減らすことができます。 また、スタックのサイズを監視したり、上限を設けたりすることも可能になります。

計算量を意識したアルゴリズム選択

再帰の危険性の一つは「計算量の爆発」です。 フィボナッチのように、再帰が枝分かれするアルゴリズムは、 素直に書くと O(2ⁿ) という非常に重い計算量になります。

セキュリティの観点では、「外部入力から n を受け取る」ようなコードで このようなアルゴリズムを使うことは極めて危険です。

そこで重要になるのが、「アルゴリズムを選び直す」という発想です。 フィボナッチなら、再帰版ではなくループ版や動的計画法版、行列累乗版を使う。 ツリー探索なら、不要な枝を早めに切る枝刈りを導入する。 バックトラッキングなら、制約を強めて探索空間を減らす。

例えば、フィボナッチを安全に計算する API を設計するなら、 次のような方針が考えられます。

n の上限を決める 素直な再帰版は使わない O(n) または O(log n) のアルゴリズムを採用する

これは「セキュリティ＝入力チェック＋アルゴリズム選択」という視点の典型例です。

例外処理とエラーメッセージの設計

再帰が原因で StackOverflowError やその他の例外が発生したとき、 その扱い方もセキュリティ上重要です。

もしスタックトレースをそのまま外部に返してしまうと、 内部のクラス構成やメソッド名、ファイル名、行番号などが攻撃者に漏洩します。 これは、攻撃者にとって「システム内部を推測するためのヒント」になります。

安全な設計としては、次のような方針が考えられます。

内部ではスタックトレースをログに記録する 外部には「一般的なエラーメッセージ」だけを返す 「どのメソッドで落ちたか」を外部に見せない

例えば、Webアプリケーションで再帰が原因の例外が発生した場合、 ユーザーには「内部エラーが発生しました。時間をおいて再度お試しください。」 といったメッセージだけを返し、 詳細なスタックトレースはサーバー側のログにのみ残すべきです。

安全な再帰の書き方の具体的なパターン

ここまでの内容を踏まえて、「安全な再帰」の具体的なパターンを整理してみます。

まず、終了条件を明確にし、入力に対して必ず到達することを確認すること。 例えば、次のようなコードでは、終了条件が「n == 0」であり、 呼び出しごとに n が減っていくため、必ず終了します。

public static int safeFactorial(int n) {
    if (n < 0) {
        throw new IllegalArgumentException("n must be non-negative");
    }
    if (n == 0) return 1;
    return n * safeFactorial(n - 1);
}

public static int safeFactorial(int n) {
    if (n < 0) {
        throw new IllegalArgumentException("n must be non-negative");
    }
    if (n == 0) return 1;
    return n * safeFactorial(n - 1);
}

ここでは、負の値に対して例外を投げることで、 終了条件を踏まない入力を事前に排除しています。 この「入力チェック」は、セキュリティの観点から非常に重要です。

次に、深さやサイズに上限を設けること。 ツリー探索やディレクトリ走査では、 最大深さや最大ノード数を決めておき、それを超えたら処理を打ち切る設計が有効です。

さらに、外部入力に対しては「再帰よりも非再帰を優先する」という方針も有効です。 非再帰版であれば、スタックオーバーフローのリスクを減らしつつ、 自分でメモリや深さを制御しやすくなります。

再帰とセキュリティを結びつけて考える癖をつける

再帰はアルゴリズムの世界では「きれいな道具」として扱われがちですが、 セキュリティの世界では「入力に依存して暴走し得る構造」として見られます。

そのため、次のような癖を持つことが重要です。

外部入力に対して再帰を使うときは、必ず深さとサイズを意識する 終了条件が入力に依存していないかを確認する 計算量が現実的かどうかを検証する 例外発生時に内部情報を漏らさないようにする

この癖が身につくと、 再帰は「危険なテクニック」ではなく「安全に使いこなせる道具」になります。

後半のまとめ

後半では、再帰のセキュリティ上の注意点に対して

深さ制限の設計 非再帰化という選択肢 計算量を意識したアルゴリズム選択 例外処理とエラーメッセージの設計 安全な再帰の具体的な書き方

を整理しました。

再帰は、ツリー探索やアルゴリズム学習において非常に強力な道具ですが、 入力と結びついた瞬間にセキュリティの問題と直結します。 「きれいさ」と「安全性」を両立させる視点を持つことが、 再帰を本当に使いこなすための鍵です。