Echo Resource Protection

Introduction

Resource protection is a crucial aspect of web application security. In the context of the Echo web framework, resource protection refers to the mechanisms that ensure only authorized users can access specific resources or perform certain operations. This guide will explain how to implement effective resource protection strategies in your Echo applications.

Resource protection is closely tied to authorization, which is the process of determining whether an authenticated user has permission to access a particular resource or perform a specific action. While authentication verifies the identity of a user, authorization decides what that user can do within the application.

Understanding Resource Types

Before implementing protection mechanisms, it's important to understand the types of resources you might need to protect:

Routes: Specific URL endpoints in your application
Data: Information stored in your databases or files
Operations: Actions like creating, reading, updating, or deleting data
Static assets: Files served by your application

Basic Authorization Middleware

Echo makes it easy to create middleware that can protect resources. Let's start with a basic middleware that checks if a user is authorized:

go
package middleware

import (
	"github.com/labstack/echo/v4"
	"net/http"
)

// Authorize is a middleware that checks if a user is authorized to access a resource
func Authorize(next echo.HandlerFunc) echo.HandlerFunc {
	return func(c echo.Context) error {
		// Get user from context (assuming it was set during authentication)
		user := c.Get("user")
		
		if user == nil {
			return c.JSON(http.StatusUnauthorized, map[string]string{
				"error": "Unauthorized access",
			})
		}
		
		// User is authorized, proceed with the request
		return next(c)
	}
}

Role-Based Access Control (RBAC)

A common approach to resource protection is Role-Based Access Control (RBAC). Here's how you can implement a simple RBAC system:

go
// Role-based authorization middleware
func RequireRole(role string) echo.MiddlewareFunc {
	return func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			// Get user from context
			user, ok := c.Get("user").(User)
			if !ok {
				return c.JSON(http.StatusUnauthorized, map[string]string{
					"error": "Unauthorized access",
				})
			}
			
			// Check if user has the required role
			hasRole := false
			for _, r := range user.Roles {
				if r == role {
					hasRole = true
					break
				}
			}
			
			if !hasRole {
				return c.JSON(http.StatusForbidden, map[string]string{
					"error": "Insufficient permissions",
				})
			}
			
			// User has the required role, proceed with the request
			return next(c)
		}
	}
}

To use this middleware:

go
// Define routes with role-based protection
e := echo.New()

// Public routes
e.GET("/", publicHandler)

// Protected routes
admin := e.Group("/admin")
admin.Use(middleware.RequireRole("admin"))
admin.GET("/dashboard", adminDashboardHandler)

// Routes for both admin and manager roles
e.GET("/reports", reportHandler, middleware.RequireRole("admin"), middleware.RequireRole("manager"))

Permission-Based Access Control

For more granular control, you might want to implement permission-based access control:

go
// Permission-based authorization middleware
func RequirePermission(permission string) echo.MiddlewareFunc {
	return func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			// Get user from context
			user, ok := c.Get("user").(User)
			if !ok {
				return c.JSON(http.StatusUnauthorized, map[string]string{
					"error": "Unauthorized access",
				})
			}
			
			// Check if user has the required permission
			if !user.HasPermission(permission) {
				return c.JSON(http.StatusForbidden, map[string]string{
					"error": "Insufficient permissions",
				})
			}
			
			// User has the required permission, proceed with the request
			return next(c)
		}
	}
}

Resource-Level Protection

Sometimes you need to protect specific resources based on ownership or other attributes:

go
// Protect a specific resource
func ProtectResource(resourceType string) echo.MiddlewareFunc {
	return func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			// Get user from context
			user, ok := c.Get("user").(User)
			if !ok {
				return c.JSON(http.StatusUnauthorized, map[string]string{
					"error": "Unauthorized access",
				})
			}
			
			// Get resource ID from URL parameter
			resourceID := c.Param("id")
			
			// Check if user can access this resource
			// This would typically involve a database query
			canAccess, err := checkResourceAccess(user.ID, resourceType, resourceID)
			if err != nil {
				return c.JSON(http.StatusInternalServerError, map[string]string{
					"error": "Error checking resource access",
				})
			}
			
			if !canAccess {
				return c.JSON(http.StatusForbidden, map[string]string{
					"error": "You don't have access to this resource",
				})
			}
			
			// User can access the resource, proceed with the request
			return next(c)
		}
	}
}

Real-World Example: Blog Application

Let's look at a comprehensive example for a blog application:

go
package main

import (
	"github.com/labstack/echo/v4"
	"github.com/labstack/echo/v4/middleware"
	"net/http"
)

type User struct {
	ID          string
	Username    string
	Roles       []string
	Permissions []string
}

func (u *User) HasPermission(permission string) bool {
	for _, p := range u.Permissions {
		if p == permission {
			return true
		}
	}
	return false
}

func main() {
	e := echo.New()
	
	// Middleware
	e.Use(middleware.Logger())
	e.Use(middleware.Recover())
	
	// Public routes
	e.GET("/", func(c echo.Context) error {
		return c.String(http.StatusOK, "Welcome to the Blog!")
	})
	
	e.GET("/posts", func(c echo.Context) error {
		// Return all published posts
		return c.String(http.StatusOK, "List of all published posts")
	})
	
	// Authentication middleware (simplified)
	authenticate := func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			// In a real app, you would validate tokens, etc.
			// For demonstration, we'll create a mock user
			user := &User{
				ID:          "user123",
				Username:    "john_doe",
				Roles:       []string{"user"},
				Permissions: []string{"read:posts"},
			}
			
			c.Set("user", user)
			return next(c)
		}
	}
	
	// Authenticated routes
	auth := e.Group("/auth")
	auth.Use(authenticate)
	
	auth.GET("/profile", func(c echo.Context) error {
		user := c.Get("user").(*User)
		return c.String(http.StatusOK, "Profile for: "+user.Username)
	})
	
	// Admin routes with role-based protection
	admin := e.Group("/admin")
	admin.Use(authenticate)
	admin.Use(func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			user := c.Get("user").(*User)
			
			// Check for admin role
			isAdmin := false
			for _, role := range user.Roles {
				if role == "admin" {
					isAdmin = true
					break
				}
			}
			
			if !isAdmin {
				return c.JSON(http.StatusForbidden, map[string]string{
					"error": "Admin access required",
				})
			}
			
			return next(c)
		}
	})
	
	admin.GET("/dashboard", func(c echo.Context) error {
		return c.String(http.StatusOK, "Admin Dashboard")
	})
	
	// Resource-specific protection for posts
	e.GET("/posts/:id", func(c echo.Context) error {
		// Public posts are accessible to everyone
		return c.String(http.StatusOK, "Post details for ID: "+c.Param("id"))
	}, authenticate)
	
	e.PUT("/posts/:id", func(c echo.Context) error {
		// Only the author or an admin can update a post
		postID := c.Param("id")
		user := c.Get("user").(*User)
		
		// In a real app, you'd check if the user is the author or an admin
		isAuthorOrAdmin := checkIfAuthorOrAdmin(user, postID)
		
		if !isAuthorOrAdmin {
			return c.JSON(http.StatusForbidden, map[string]string{
				"error": "Only the author or an admin can update this post",
			})
		}
		
		return c.String(http.StatusOK, "Post updated successfully")
	}, authenticate)
	
	e.Logger.Fatal(e.Start(":8080"))
}

func checkIfAuthorOrAdmin(user *User, postID string) bool {
	// In a real application, this would query the database
	// to check if the user is the author of the post or has admin role
	
	// Simplified logic for demonstration
	for _, role := range user.Roles {
		if role == "admin" {
			return true
		}
	}
	
	// Check if user is author (mock implementation)
	return user.ID == "author_of_"+postID
}

Best Practices for Resource Protection

Defense in Depth: Apply multiple layers of protection
Least Privilege: Give users only the permissions they need
Fail Secure: Default to denying access when authorization fails
Consistent Authorization: Apply authorization checks consistently across all resources
Validate at the Server Side: Never rely on client-side authorization checks
Audit and Log: Keep records of authorization decisions, especially denials
Use Middleware: Implement authorization as middleware for consistency

Common Pitfalls to Avoid

Insecure Direct Object References: Don't expose internal object references in URLs without authorization
Missing Function Level Authorization: Check permissions for every function, not just at the route level
Horizontal Privilege Escalation: Ensure users can't access resources owned by other users at the same permission level
Vertical Privilege Escalation: Prevent users from gaining higher permissions than assigned

Summary

Resource protection in Echo applications involves creating middleware that checks user authentication status, roles, permissions, and resource ownership before allowing access. Echo's middleware system makes it straightforward to implement various authorization strategies:

Basic Authorization: Simple checks for authenticated users
Role-Based Access Control: Protecting resources based on user roles
Permission-Based Authorization: More granular control using specific permissions
Resource-Level Protection: Checking ownership or access rights for specific resources

By implementing proper resource protection, you ensure that your application's data and functionality are only accessible to users with appropriate permissions, enhancing your application's security posture.

Additional Resources

Exercises

Implement a middleware that restricts access to API endpoints based on the HTTP method (e.g., only admins can DELETE).
Create a middleware that implements API rate limiting based on user roles.
Extend the blog example to include a "moderator" role that can edit any post but not delete them.
Implement a permission system where permissions can be inherited through role hierarchies.

If you spot any mistakes on this website, please let me know at [email protected]. I’d greatly appreciate your feedback! :)

Introduction​

Understanding Resource Types​

Basic Authorization Middleware​

Role-Based Access Control (RBAC)​

Permission-Based Access Control​

Resource-Level Protection​

Real-World Example: Blog Application​

Best Practices for Resource Protection​

Common Pitfalls to Avoid​

Summary​

Additional Resources​

Exercises​