Laravel 5.5：含公共与认证用户字段的表是否需要拆分？

Hey there! Let's tackle your question head-on—first addressing your biggest security concern, then breaking down the pros and cons of splitting the table, and finally giving you actionable advice tailored to Laravel.

First: The Critical Data Leak Risk You're Worried About #

You’re absolutely right to be concerned! If your controller/function is returning the full model (all columns) right now, any non-browser request (like Postman, cURL, or a custom script) will receive every single field, even if your view only displays public ones. This is a real security gap, and it’s not dependent on whether you split the table or not—this needs fixing immediately, regardless of your table structure.

Should You Split the Table? Let's Weigh the Options #

Reasons to Split the Table #

• Clearer Data Isolation: Splitting enforces physical separation between public and sensitive data, aligning with the single responsibility principle. It reduces the chance of accidentally exposing sensitive fields through oversight (like forgetting to restrict a query).
• Simplified Permission Controls: You can apply tighter database-level permissions to the authenticated-only table if needed, and queries for public data won’t even touch the sensitive table by default.
• Scalability for Future Changes: If you anticipate adding more authenticated-only fields down the line, splitting now keeps your data model organized and avoids bloating a single table with mixed-use fields.

Reasons to Avoid Splitting #

• Increased Complexity: You’ll need to manage model relationships (like hasOne/belongsTo), join queries when fetching full user data, and extra migrations/maintenance for two tables instead of one.
• Unnecessary Overhead: If you only have a small number of sensitive fields that are tightly coupled with the public ones, splitting adds complexity without much tangible benefit.

Actionable Fixes (Regardless of Table Split Decision) #

No matter if you split the table or not, you must implement these controls to prevent data leaks:

1. Control Data Returns Explicitly
   Never rely on views to hide data—handle it at the backend level:

   • Select Specific Fields: Only fetch the fields you need for each request:

     // For guests: fetch only public fields
     $data = YourModel::select('public_field_1', 'public_field_2')->find($id);
     
     // For authenticated users: include sensitive fields
     if (auth()->check()) {
         $data = YourModel::select('public_field_1', 'public_field_2', 'sensitive_field_1', 'sensitive_field_2')->find($id);
     }
     

   • Use Laravel API Resources (Recommended): This is the most flexible way to tailor responses based on user authentication status:

     class YourModelResource extends JsonResource
     {
         public function toArray($request)
         {
             $response = [
                 'public_field_1' => $this->public_field_1,
                 'public_field_2' => $this->public_field_2,
             ];
     
             // Add sensitive fields only for authenticated users
             if (auth()->check()) {
                 $response['sensitive_field_1'] = $this->sensitive_field_1;
                 $response['sensitive_field_2'] = $this->sensitive_field_2;
             }
     
             return $response;
         }
     }
     
     // In your controller:
     return new YourModelResource(YourModel::find($id));
     

   • Model Hidden Attributes: Hide sensitive fields globally, then make them visible for authenticated users when needed:

     class YourModel extends Model
     {
         protected $hidden = ['sensitive_field_1', 'sensitive_field_2'];
     }
     
     // In controller for authenticated users:
     $data = YourModel::find($id)->makeVisible(['sensitive_field_1', 'sensitive_field_2']);
     

2. Enforce Route/Controller Permissions
   Make sure your routes or controller methods explicitly check user status. For example:

   // Route for public data (guests allowed)
   Route::get('/data/{id}', [DataController::class, 'showPublic']);
   
   // Route for authenticated-only full data
   Route::get('/data/{id}/full', [DataController::class, 'showFull'])->middleware('auth');
   

Final Recommendation #

• Split the table if: You have a significant number of sensitive fields, the sensitive data has distinct business logic from public data, or you need strict physical isolation for compliance/security reasons.
• Don't split if: You only have a handful of sensitive fields that are closely tied to the public data, and you prefer to keep your data model simple.

Remember: The biggest risk right now is your function returning all columns. Fix that first, then decide on the table structure based on your long-term needs.

内容的提问来源于stack exchange，提问作者Rakesh kumar